Кратко

  • FCS в PPP охватывал заданные поля кадра, но не Flags, стартовые и стоповые биты и не материал, вставленный ради прозрачности. Передатчик выполнял stuffing после расчёта, а приёмник отменял его до проверки.
  • Приёмная ACCM разрешала до FCS удалить только выбранные управляющие символы со значением ниже 0x20: их могло вставить промежуточное оборудование. Это узкое правило для одного направления, а не право стирать произвольные изменения.
  • Octet stuffing и bit stuffing решали одну задачу разными представлениями. Правильный FCS свидетельствовал об обнаружении ошибок в восстановленном кадре, но не об идентичности, аутентификации или неизменности физического тракта.

След на линии ещё не становился частью кадра

В последовательной записи появляется управляющий символ, которого отправитель не включал в пакет. Его мог добавить модем, драйвер терминала или другое коммуникационное устройство. Если посчитать FCS вместе с ним, исправный кадр окажется ошибочным. Если приёмник сможет удалять всё неожиданное, он скроет настоящую порчу данных.

RFC 1662 проводит границу иначе. До вычисления FCS удаляются октеты, отмеченные в приёмной Async-Control-Character-Map, и отменяются последовательности Control Escape. Проверяется кадр PPP, восстановленный по общим правилам, а не каждый физический октет, замеченный в любой точке пути.

Слово «канонизация» здесь лишь удобное редакционное описание. В RFC нет поля с таким названием; значение имеют закрытый набор преобразований и их порядок.

Сначала проверочное значение, потом маскировка для линии

HDLC-like кадр ограничивают Flags со значением 0x7e. Между ними находятся Address, Control, Protocol, Information, необязательный Padding и FCS. По умолчанию FCS имеет 16 бит, также определена 32-битная форма. В расчёт входят поля от Address до Padding, но не Flags, не сам FCS, не стартовые и стоповые биты и не вставки прозрачности.

При octet stuffing значение 0x7d служит Control Escape. Отправитель обязан экранировать как минимум 0x7e и 0x7d. Порядок принципиален: сначала вычисляется FCS, затем содержимое между Flags просматривается для передачи. Защищаемый октет заменяется на 0x7d и исходное значение XOR 0x20. Поэтому 0x7e превращается в 0x7d 0x5e, а 0x7d — в 0x7d 0x5d.

Приёмник выполняет обратное до проверки: удаляет Control Escape и применяет XOR 0x20 к следующему октету. Если сразу после Escape следует Flag, кадр прерывается, а не превращается в обычные данные. Удалять временную форму можно потому, что преобразование однозначно и обратимо.

ACCM задавала минимум для одного направления

ASCII-управление конфликтовало с особенностями асинхронных линий. Программный flow control мог перехватить XON 0x11 или XOFF 0x13, иногда не учитывая бит чётности. PPP позволял экранировать эти значения, а на приёме удалять настроенные младшие управляющие символы, которые мог добавить тракт.

Каждый асинхронный конец имел две карты: 32-битную приёмную ACCM для значений ниже 0x20 и передающую карту длиной до 256 бит. На двунаправленной связи существовало четыре карты, а не один глобальный список запретов.

Опция LCP ACCM имеет тип 2, длину 6 и четырёхоктетную bitmap. Единица требует от peer сохранять соответствующий символ в mapped form при отправке к запросившей стороне. Ноль означает только отсутствие обязанности; экранирование не запрещается. Передатчик вправе защищать дополнительные значения из-за известных ему местных ограничений.

Приёмник определяет минимальную защиту входящего пути, а отправитель может действовать осторожнее. Configure-Nak должен предлагать объединение необходимых наборов, чтобы случайно вставленные трактом символы можно было игнорировать при получении. Локальное требование остаётся привязанным к направлению.

Синхронный вариант вставлял бит, а не escape-октет

Bit-synchronous framing применяет другой метод. После расчёта FCS передатчик вставляет ноль после каждой последовательности из пяти единиц, включая последовательности внутри FCS. До своего расчёта приёмник удаляет этот ноль. Внутри кадра не возникает ложного Flag.

Общий инвариант — прозрачность добавляется после создания проверочного значения и снимается до проверки. Представления на линии различны. Асинхронно-синхронный преобразователь отвечает за перевод stuffing. RFC 1662 требует, чтобы синхронная реализация подтверждала опцию ACCM ради совместимости с преобразователем, но подчёркивает: подтверждение не доказывает, что сам синхронный endpoint выполняет octet mapping.

Принятая настройка может обслуживать промежуточный компонент и не указывает место исполнения.

Отброшенный кадр не обязательно увеличивал счётчик FCS

Слишком короткий кадр, Control Escape непосредственно перед закрывающим Flag или нарушение octet framing отбрасываются без сообщения и не считаются FCS error. В bit-stuffed режиме недопустимая последовательность более чем из шести единиц относится к той же категории.

Поэтому одного счётчика FCS недостаточно. Capture после драйвера, уже снявшего escapes, показывает не тот объект, что сырая последовательная запись. Анализатор с неверной ACCM, режимом stuffing или шириной FCS может создать «плохую сумму», которой endpoint никогда не видел.

Минимальная карточка инцидента должна содержать направление, приёмные и передающие карты, режим линии, вид FCS, место захвата, стадию decoding, счётчики недействительных кадров, сырые и восстановленные байты.

Полином не удостоверял отправителя

RFC 1570 определил Null, 16- и 32-битные варианты по направлениям и фазам. RFC 1662 рекомендовал 32-битную форму при NRZI, поскольку NRZI ухудшает свойства обнаружения 16-битного FCS. Это настройки обнаружения ошибок, а не аутентификация.

В разделе безопасности RFC 1662 отдельно сказано, что link layer может не узнать о смене физического соединения, а вставка или подмена calling identity способна обойти другие предположения о доверии. Кадр из неправильного физического продолжения может иметь безупречный FCS. Полином проверяет биты, не право их отправлять.

Историческая сила PPP заключалась в малом исключении. Тракт мог адаптировать представление, не переопределяя payload, поскольку исключения были перечислены, направлены и обратимы. Превращение этой нормы в общее разрешение удалять неудобные байты уничтожило бы сам объект защиты.

Источники