Zusammenfassung

  • Der PPP-FCS erfasste die definierten Rahmenfelder, nicht Flags, Start-/Stopbits oder für Transparenz eingefügtes Material. Der Sender führte Stuffing nach der Berechnung aus, der Empfänger machte es vor der Prüfung rückgängig.
  • Die Empfangs-ACCM erlaubte nur das Entfernen ausgewählter Steuerzeichen unter 0x20 vor dem FCS, weil Zwischenanlagen solche Zeichen einfügen konnten. Das war eine gerichtete, enge Regel und keine Erlaubnis, beliebige Änderungen zu löschen.
  • Octet Stuffing und Bit Stuffing lösten dasselbe Abgrenzungsproblem mit unterschiedlichen Darstellungen. Ein gültiger FCS belegte Fehlererkennung am rekonstruierten Rahmen, nicht Identität, Authentisierung oder einen unveränderten physischen Weg.

Ein zusätzliches Zeichen konnte außerhalb des Rahmens liegen

Eine serielle Aufzeichnung enthält ein Steuerzeichen, das der sendende Endpunkt nicht in den Rahmen geschrieben hat. Ein Modem, Terminaltreiber oder anderes Datenkommunikationsgerät könnte es eingefügt haben. Nimmt der Empfänger es in die Prüfsumme auf, fällt ein intakter Rahmen durch. Entfernt er nach Belieben unerwartete Bytes, kann echte Nutzdatenkorruption verschwinden.

RFC 1662 definierte daher eine kleine Ausnahme. Zeichen, deren Bit in der Empfangs-ACCM gesetzt ist, werden vor der FCS-Berechnung entfernt. Control-Escape-Folgen werden ebenfalls rückgängig gemacht. Geprüft wird der nach gemeinsamen Regeln wiederhergestellte PPP-Rahmen, nicht jede physische Erscheinung entlang der Leitung.

„Kanonisierung“ ist dafür nur eine redaktionelle Kurzform. Das RFC führt kein Feld dieses Namens. Verbindlich sind die aufgezählten Transformationen und ihre Reihenfolge.

Der Prüfwert entstand vor der Leitungsdarstellung

Ein HDLC-like-Rahmen wird durch Flags mit dem Wert 0x7e begrenzt. Dazwischen liegen Address, Control, Protocol, Information, optionales Padding und der FCS. Standard sind 16 Bit; eine 32-Bit-Form ist ebenfalls definiert. Der FCS umfasst Address bis Padding, nicht die Flags, sich selbst, asynchrone Start-/Stopbits oder Transparenzeinfügungen.

Bei Octet Stuffing ist 0x7d das Control Escape. Mindestens 0x7e und 0x7d müssen geschützt werden. Zuerst berechnet der Sender den FCS. Danach ersetzt er jedes betroffene Byte zwischen den Flags durch 0x7d und den ursprünglichen Wert XOR 0x20. Aus 0x7e wird 0x7d 0x5e, aus 0x7d wird 0x7d 0x5d.

Der Empfänger kehrt dies vor seiner Prüfung um. Er entfernt Control Escape und verknüpft das folgende Byte mit XOR 0x20. Folgt unmittelbar ein Flag, wird der Rahmen abgebrochen; es entsteht kein normales Datenbyte. Die temporäre Darstellung darf verschwinden, weil sie explizit und reversibel ist.

Die ACCM beschrieb eine Richtung

ASCII-Steuerzeichen kollidierten mit asynchronen Übertragungswegen. Software-Flusskontrolle konnte XON bei 0x11 oder XOFF bei 0x13 abfangen, teilweise ohne das Paritätsbit zu beachten. PPP konnte diese Werte escapen und am Empfang konfigurierte niedrige Steuerzeichen entfernen, die auf dem Weg hinzugekommen sein konnten.

Jeder asynchrone Endpunkt hielt zwei Karten: eine 32-Bit-Empfangs-ACCM für Werte unter 0x20 und eine Sende-ACCM mit bis zu 256 Bit. Über beide Endpunkte existierten vier Karten. Es gab keine globale Zeichenverbotsliste.

Die LCP-Option ACCM hat Typ 2, Länge 6 und eine vier Byte große Bitmap. Ein gesetztes Bit verpflichtet den Peer, das entsprechende Zeichen auf dem Weg zum Anforderer gemappt zu lassen. Ein gelöschtes Bit bedeutet nur, dass Mapping nicht nötig ist. Der Sender darf wegen lokal bekannter Leitungsbedingungen weitere Werte escapen.

Der Empfänger bestimmt somit den Mindestschutz seiner Eingangsrichtung, der Sender behält konservativen Spielraum. Ein Configure-Nak soll die Vereinigungsmenge der Anforderungen vorschlagen, damit unterwegs irrtümlich eingefügte Zeichen am Ziel erkannt werden. Lokales Wissen bleibt lokal.

Auf synchronen Links wurde ein Bit statt eines Escape-Bytes ergänzt

Bit-synchronous Framing verwendet nicht den 0x7d-Mechanismus. Nach der FCS-Berechnung fügt der Sender nach jeder Folge von fünf Einsen eine Null ein, auch innerhalb des FCS. Vor der Empfangsberechnung entfernt der Empfänger sie. Dadurch kann das Flag-Muster nicht zufällig im Rahmen entstehen.

Beide Verfahren teilen die Reihenfolge, nicht das Leitungsbild. Ein Asynchron-Synchron-Konverter übersetzt das Stuffing. RFC 1662 verlangt, dass eine synchrone Implementierung die ACCM-Option für solche Konverter bestätigt, stellt aber klar, dass diese Bestätigung kein Beleg dafür ist, dass der synchrone Endpunkt selbst Octet Mapping ausführt.

Eine akzeptierte Konfiguration kann also die Arbeit eines Zwischenstücks ermöglichen. Sie lokalisiert die Implementierung nicht.

Verworfen bedeutete nicht automatisch FCS-Fehler

Zu kurze Rahmen, ein hängendes Control Escape direkt vor dem Abschluss-Flag oder verletztes Octet Framing werden still verworfen und nicht als FCS-Fehler gezählt. Im Bit-Stuffing-Modus gilt eine ungültige Folge von mehr als sechs Einsen ebenfalls als Framingfehler.

Wer nur den FCS-Zähler beobachtet, kann den eigentlichen Defekt übersehen. Eine Aufzeichnung hinter einem Treiber, der Escape-Material bereits entfernt hat, enthält ein anderes Objekt als die rohe serielle Seite. Ein Analyzer mit falscher ACCM, falschem Modus oder falscher FCS-Breite kann einen Fehler erzeugen, den der Endpunkt nie sah.

Zum Mindestnachweis gehören Richtung, Sende- und Empfangskarten, Linkmodus, FCS-Form, Aufzeichnungspunkt, Decodierstufe, Zähler ungültiger Rahmen sowie rohe und rekonstruierte Bytes.

Der FCS war keine Identitätsprüfung

RFC 1570 definierte Null-, 16- und 32-Bit-Alternativen nach Richtung und Protokollphase. RFC 1662 empfahl bei NRZI die 32-Bit-Form, weil NRZI die Erkennungseigenschaften des 16-Bit-FCS schwächt. Beides betrifft Fehlererkennung, nicht Authentisierung.

Die Sicherheitsbetrachtung in RFC 1662 warnt getrennt davor, dass die Sicherungsschicht einen Wechsel der geschalteten physischen Verbindung übersehen kann. Einfügen oder eine vorgetäuschte Anruferidentität kann andere Vertrauensannahmen unterlaufen. Ein Rahmen aus der falschen physischen Fortsetzung kann trotzdem einen perfekten FCS tragen. Das Polynom prüft Bits, keine Berechtigung.

Die historische Leistung von PPP lag in der engen Grenze. Ein serieller Weg durfte die Darstellung anpassen, ohne den Nutzinhalt neu zu definieren, weil die Ausnahmen aufgezählt, gerichtet und reversibel blieben. Wer daraus eine allgemeine Löschbefugnis macht, zerstört genau den Rahmen, dessen Integrität geschützt werden sollte.

Quellen