Résumé

  • Le FCS de PPP porte sur les champs définis de la trame, pas sur les fanions, les bits de départ et d’arrêt ni sur les éléments ajoutés pour la transparence. L’émetteur bourre après le calcul ; le récepteur déboure avant la vérification.
  • L’ACCM de réception ne permet de supprimer avant le FCS que les caractères inférieurs à 0x20 dont les bits sont sélectionnés, car des équipements intermédiaires peuvent les insérer. Cette exception directionnelle n’autorise pas l’effacement arbitraire.
  • Le bourrage d’octets et celui de bits utilisent des représentations différentes. Un FCS valide atteste une détection d’erreur sur la trame reconstruite, non l’identité du pair, son authentification ou l’absence de modification du trajet physique.

Une trace série ne définit pas encore la trame

Un caractère de contrôle apparaît dans la capture, mais l’application émettrice ne l’a jamais envoyé. Un modem, un pilote de terminal ou un autre équipement de communication a pu l’introduire. L’inclure aveuglément dans le calcul ferait échouer une trame intacte. L’ignorer sans règle permettrait au contraire de masquer une altération de données.

PPP résout ce dilemme en définissant l’objet du contrôle. Le RFC 1662 demande de retirer, avant le calcul FCS, les octets signalés dans l’Async-Control-Character-Map de réception. Il demande aussi d’annuler les séquences d’échappement. La somme porte ainsi sur ce que les deux extrémités reconnaissent comme la trame PPP, et non sur tout phénomène traversant le support.

On peut appeler cela une canonicalisation pour expliquer l’enchaînement, mais le terme n’est pas un champ du protocole. La garantie vient d’une liste fermée de transformations et de leur ordre.

Le déguisement venait après la somme

La trame HDLC-like est bornée par la valeur Flag 0x7e. Entre les deux fanions figurent Address, Control, Protocol, Information, éventuellement Padding, puis le FCS. Celui-ci vaut 16 bits par défaut ; une forme de 32 bits est également définie. Son domaine s’étend d’Address à Padding. Il exclut le FCS lui-même, les fanions, les bits start/stop et tout élément inséré pour la transparence.

Sur un lien à bourrage d’octets, 0x7d joue le rôle de Control Escape. L’émetteur doit au minimum protéger 0x7e et 0x7d. Il calcule d’abord le FCS, puis parcourt le contenu situé entre les fanions. Chaque valeur à protéger devient deux octets : 0x7d, suivi de la valeur originale XOR 0x20. Ainsi, 0x7e devient 0x7d 0x5e et 0x7d devient 0x7d 0x5d.

Le récepteur effectue l’inverse avant son contrôle : il retire Control Escape et applique XOR 0x20 à l’octet suivant. Si un fanion suit immédiatement l’échappement, la trame est abandonnée. Le mécanisme ne repose pas sur une intuition concernant les données ; il repose sur une transformation explicite et réversible.

Quatre cartes pour deux directions

Les caractères de contrôle ASCII étaient une contrainte réelle des liaisons asynchrones. Le contrôle de flux logiciel pouvait intercepter XON, 0x11, ou XOFF, 0x13, parfois sans tenir compte du bit de parité. L’échappement permettait de transporter ces valeurs, tandis que la carte de réception permettait de retirer celles que le trajet risquait d’ajouter.

Chaque extrémité asynchrone conserve une ACCM de réception sur 32 bits et une ACCM d’émission pouvant atteindre 256 bits. Il existe donc quatre cartes sur une liaison bidirectionnelle. Ce n’est ni une table universelle ni une interdiction globale de caractères.

L’option LCP ACCM est de type 2, de longueur 6, avec un bitmap de quatre octets. Un bit à 1 impose au pair de maintenir le caractère correspondant sous forme échappée lorsqu’il émet vers le demandeur. Un bit à 0 signifie seulement que ce traitement n’est pas obligatoire. L’émetteur peut en protéger davantage s’il connaît une contrainte locale de son trajet.

La répartition de l’autorité est fine. Le récepteur exprime le minimum nécessaire sur le chemin entrant. L’émetteur conserve une marge de prudence. Un Configure-Nak devrait proposer l’union des ensembles requis afin que les caractères ajoutés sans raison par le trajet puissent être reconnus à l’arrivée. Une exigence locale ne devient jamais une règle pour toutes les liaisons.

Le cousin synchrone ajoutait des bits

Sur une liaison bit-synchronous, l’octet 0x7d n’est pas la solution. Après le calcul FCS, l’émetteur insère un zéro après chaque série de cinq bits à 1, y compris dans le FCS. Le récepteur retire ce zéro avant son propre calcul. La séquence du fanion ne peut donc pas surgir accidentellement dans le corps de la trame.

Les deux techniques partagent une invariant : ajouter la transparence après avoir produit la valeur de contrôle, puis l’enlever avant de la vérifier. Elles ne partagent pas la même image sur le fil. Un convertisseur asynchrone-synchrone doit traduire le bourrage. Le RFC 1662 exige même qu’une implémentation synchrone accepte l’option ACCM pour permettre ce convertisseur, tout en précisant que cet accord ne prouve pas qu’elle effectue elle-même le mapping d’octets.

Une option acceptée peut donc décrire le besoin d’un intermédiaire. Elle ne localise pas à elle seule le code qui réalise l’opération.

Une trame rejetée n’était pas forcément un échec FCS

PPP distingue les erreurs de forme du contrôle FCS. Une trame trop courte, un Control Escape suspendu juste avant le fanion de fermeture ou une violation du cadrage d’octets sont silencieusement rejetés sans incrémenter le compteur FCS. Dans la variante bit-stuffed, plus de six bits à 1 consécutifs constituent également une trame invalide.

Un tableau de bord limité aux erreurs FCS peut donc manquer le défaut principal. Une capture réalisée après le débourement par le pilote ne montre pas le même objet qu’une capture série brute. Un analyseur utilisant la mauvaise ACCM, le mauvais mode ou la mauvaise largeur FCS peut inventer une erreur que l’extrémité n’a jamais calculée.

Le dossier minimal d’incident doit conserver la direction, les cartes d’envoi et de réception, le type de liaison, la forme du FCS, le point de capture, l’étape de décodage, les compteurs de trames invalides, ainsi que les octets bruts et reconstruits.

La sécurité commençait au-delà du polynôme

Le RFC 1570 a défini des alternatives FCS Null, 16 bits et 32 bits par direction, avec des règles selon la phase du lien. Le RFC 1662 a aussi recommandé 32 bits lorsque le codage NRZI affaiblissait les propriétés de la variante 16 bits. Ces choix améliorent ou modifient la détection d’erreur ; ils n’authentifient personne.

La section de sécurité du RFC 1662 avertit séparément qu’une couche liaison peut ignorer un changement de connexion physique et qu’une insertion ou une identité d’appel usurpée peut contourner d’autres hypothèses. Une trame venant de la mauvaise continuité physique peut posséder un FCS parfait. Le polynôme répond à une question sur les bits, pas sur le droit d’émettre.

L’apport historique de PPP tient à la modestie de sa frontière. Il a permis d’adapter un trajet série sans redéfinir les données, parce que les exclusions restaient énumérées, directionnelles et réversibles. Élargir cette exception à tout octet gênant détruirait l’objet même que le FCS devait protéger.

Sources