Resumo

  • O FCS do PPP abrangia os campos definidos do quadro, não Flags, bits de início e parada nem material inserido para transparência. O transmissor fazia stuffing depois do cálculo; o receptor desfazia antes da verificação.
  • O ACCM de recepção autorizava remover antes do FCS somente caracteres abaixo de 0x20 selecionados, pois equipamentos intermediários poderiam inseri-los. Era um filtro direcional e limitado, não licença para apagar alterações arbitrárias.
  • Stuffing de octetos e de bits resolviam o mesmo problema com representações diferentes. Um FCS válido demonstrava detecção de erro sobre o quadro reconstruído, não identidade, autenticação ou um caminho físico intocado.

Nem tudo o que cruzava a linha fazia parte do quadro

Um caractere de controle aparece na captura, embora o extremo transmissor não o tenha incluído. Um modem, driver de terminal ou outro equipamento de comunicação de dados pode tê-lo inserido. Se o receptor acrescentar esse caractere ao cálculo, um quadro íntegro falha. Se descartar qualquer byte inesperado, uma corrupção real pode desaparecer.

O RFC 1662 escolheu uma fronteira estreita. Octetos marcados no Async-Control-Character-Map de recepção são removidos antes do cálculo do FCS, assim como a representação Control Escape é revertida. O objeto verificado passa a ser o quadro PPP reconstruído por regras comuns, e não toda marca produzida pelo meio físico.

“Canonicalização” é uma forma editorial útil de explicar a ordem, mas não existe como campo no RFC. A disciplina está na lista fechada de transformações.

Primeiro o FCS, depois a roupa do caminho

Um quadro HDLC-like é delimitado por Flags 0x7e. Entre eles estão Address, Control, Protocol, Information, Padding opcional e FCS. A forma padrão tem 16 bits; há também uma de 32. O cálculo cobre Address até Padding, excluindo Flags, o próprio FCS, bits de início e parada e qualquer inserção de transparência.

Em um enlace com octet stuffing, 0x7d é Control Escape. O transmissor deve escapar pelo menos 0x7e e 0x7d. A sequência operacional é essencial: calcula o FCS e depois examina o conteúdo entre os Flags. Cada octeto protegido vira 0x7d seguido do valor original XOR 0x20. Assim, 0x7e se torna 0x7d 0x5e; 0x7d se torna 0x7d 0x5d.

O receptor faz o inverso antes de verificar: remove Control Escape e aplica XOR 0x20 ao octeto seguinte. Se o escape for seguido imediatamente por Flag, o quadro é abortado. A exclusão é aceitável porque a transformação é explícita e reversível, não porque o receptor possa reinterpretar livremente os dados.

O ACCM expressava uma obrigação por direção

Controles ASCII entravam em conflito com enlaces assíncronos. Controle de fluxo por software podia interceptar XON, 0x11, e XOFF, 0x13, até ignorando o bit de paridade. O PPP permitia escapar esses valores e, no sentido inverso, retirar os controles baixos configurados como possíveis inserções do caminho.

Cada extremo assíncrono mantinha dois mapas: o de recepção, com 32 bits, e o de envio, que podia alcançar 256. Uma ligação nos dois sentidos tinha quatro ACCMs, não uma lista universal de caracteres proibidos.

A opção ACCM do LCP é tipo 2, comprimento 6 e contém um bitmap de quatro octetos. Bit em um manda o peer manter o controle mapeado quando envia ao solicitante. Bit em zero diz apenas que não precisa mapear. O transmissor ainda pode escapar outros valores por restrições locais que conhece.

O receptor controla o requisito mínimo de seu caminho de entrada. O transmissor conserva liberdade para ser mais cauteloso. Um Configure-Nak deve propor a união dos conjuntos necessários, para que controles introduzidos no trajeto possam ser ignorados na chegada. A política permanece localizada em uma direção.

No enlace síncrono, a transparência era feita com bits

O bit-synchronous framing não copia o método de 0x7d. Depois de calcular o FCS, o transmissor insere um zero após toda sequência de cinco bits um, inclusive dentro do FCS. Antes do cálculo na recepção, esse zero é retirado. O corpo do quadro não simula acidentalmente o padrão de Flag.

As técnicas dividem a ordem — transparência depois da geração do FCS e retirada antes da verificação — mas não a representação no fio. Um conversor assíncrono-síncrono cuida da tradução. O RFC 1662 exige que a implementação síncrona reconheça a opção ACCM para compatibilidade com o conversor, sem concluir que o próprio endpoint faça mapeamento de octetos.

Aceitar uma opção pode sustentar o trabalho de um intermediário. Não prova onde a transformação foi executada.

Descarte de framing não era erro de FCS

Quadro curto demais, Control Escape pendente antes do Flag final ou violação de octet framing são descartados silenciosamente e não contam como erro FCS. Na modalidade por bits, uma sequência inválida de mais de seis uns recebe o mesmo tratamento.

Por isso, um painel só de FCS pode esconder a falha de framing. Uma captura posterior à remoção de escapes pelo driver não contém o mesmo objeto de uma captura serial bruta. Aplicar ACCM, stuffing ou largura de FCS errados em um analisador pode fabricar um “checksum ruim” que o endpoint nunca calculou.

O registro mínimo inclui direção, mapas de envio e recepção, modo do enlace, forma do FCS, ponto da captura, etapa do decoder, contadores de quadro inválido e bytes brutos e reconstruídos.

Detecção de erro não respondia por identidade

O RFC 1570 definiu alternativas Null, 16 e 32 bits por direção e por fase. O RFC 1662 recomendou 32 bits quando NRZI reduz as propriedades de detecção da forma de 16 bits. São escolhas sobre erro, não autenticação.

A seção de segurança do RFC 1662 alerta separadamente que a camada de enlace pode não perceber uma mudança na conexão física e que inserção ou identidade de chamada falsificada pode quebrar premissas externas. Um quadro da continuidade física errada ainda pode possuir FCS perfeito. O polinômio confere bits, não autorização.

A contribuição histórica do PPP foi tornar a exceção pequena. O caminho podia adaptar a forma de transmissão sem redefinir o payload porque as exclusões eram reversíveis, direcionais e enumeradas. Usar a regra para apagar qualquer byte inconveniente destruiria o limite de integridade que ela preservava.

Fontes