CRC вынесена вниз - и она оч хорошо считается

А не байт-два, раскиданные в разных местах

ВОТ!

так что логи мои не кривые!

Это говно даже нафаршмаченные парсеры походу не понимают

еще как понимают!

не та кс - не удет!

не та CRC - не уйдет!

Не понимают. Я беру это говно и пихаю hex в анализатор трафика, тот мне говорит что это хуйня полная.

видимо он не умеет работать с ppp

Я, блять, даже стандарт такой найти не могу

Умеет

Хер с ним с обрезанным заголовком ppp

Но нахрена порт эскейпить на ровном месте?

Бл. Я иногда не понимаю что курили очередные велосипедостроители

Escape Sequences
The HDLC information or FCS fields may contain a byte value of 7Eh, which could be
mistaken for a start/end flag, so an escape sequence is sent in its place. This consists of the
escape byte 7Dh, followed by the original value exclusive OR 20h (i.e., 7D 5Eh). The
escape character may also occur among the data, in which case it is sent as 7D 5Dh.
This escape scheme also protects control characters, which can have special meanings on
serial links. For example, software handshaking may be enabled, in which case XOFF and
XON characters (control-S and control-Q) are used by the low-level drivers to suspend and
resume serial transmissions. To avoid any confusion between XOFF and a data byte value
of 14h, the latter may be sent as the escape sequence 7D 34h. By default, all values
between 00 and lFh are escaped, but (as you've probably already guessed) the nodes can
negotiate to remove the escape sequences from some or all of these values.
It is important to remember that the escape sequence doesn't just apply to the data field, but
also the control and FCS fields, so the control field would become the two-byte value 7D
23h.

хон ксофф

+ флаги начала конец

я 2 недели над этим мозг ломал

пробовал менять ID-IP-заголовка - безрезультатно