Свой стек PPP Опции

[Beginning]

Долго искал, где создать тему, так и не нашёл. Разместил здесь, т.к. в конечном счёте, PPP необходим для GPRS. Если есть более подходящая ветка, прошу перенести.
Собственно сам вопрос. Рассчитываю CRC PPP фрейма. И CRC не совпадает. Делаю Следующее:
Сначало приходит стандартный LCP пакет:
~ }#А!}!}#} }9}"}&} }*} } }'}"}(}"}%}&ЂA}!в}#}%В#}%чи~
После преоброзования 7D, выделяем тело:
C0,21,1,3,0,19,2,6,0,A,0,0,7,2,8,2,5,6,80,41,1,E2,3,5,C2,23,5,F7,E8,

Функуия для расчёта CRC:
uint16 crc16_ppp(uint8 *buf,uint32 len)
{
uint32 i;
uint8 j;
uint16 crc=0x2E93; //В CRC побывало уже 0xFF и 0x03
for (i=0;i<len;i++)
{
crc^=(uint16)buf[i]<<8;
for(j=0;j<8;j++) crc=crc&0x8000 ? (crc << 1)^0x1021 : crc<<1;
}
return crc;
}
Получаю CRC: EB1C
Инвертирую CRC: 14E3 и оно не совпадает с F7E8.
Что я делаю не так? Через CRC надо пропускать байты уже преобразованные через 7D, или абсолютно каждый байт между ~~?
Если у кого есть исxодники PPP, можете помочь страждущему?
P.S. Т.к. есть большое желание узнать, как вся эта кухня работает, не предлагать взять готовый стек PPP и TCP/IP

[Beginning]

Помогите решить проблему.
Сразу после CONNECT, приходит первый PPP пакет – это LCP протокол согласования настроек соединения:
FF,3,C0,21,1,3,0,19,2,6,0,A,0,0,7,2,8,2,5,6,B4,DE,E,6E,3,5,C2,23,5,35,D3,
где:
FF,3 – константы
CO,21 –LCP
1 -Запрос конфигурации
3 –ID
0,19 – длина поля ”информация”
2,6,0,A,0,0, - сервер предложил только 12 13 символ передавать через ESC
7,2, - сжатие поля протокола
8,2,- сжатие полей поля адреса и управления
5,6,B4,DE,E,6E, - магическое число
3,5,C2,23,5, - протокол аутентификации CHAP !!! Зачем здесь в конце цифра 5??? Кто знает прошу объяснить.
35,D3, -CRC
Мне не нужны все предложенные настройки. Вместо протокола CHAP нужен PAP.
Следуя алгоритму, я посылаю пакет NAK. Что написано про него в описании:
Пакет LCP типа Configure-Nak используется для сигнализации о том, что по крайней мере один из параметров, заявленных в пакете Configure-Request, не принят сервером РРР. При этом сервер должен указать, какой именно параметр не принят, и предложить альтернативное значение этого параметра в поле Опции этого пакета.
Я формирую следующий пакет:
FF,3,C0,21,3,3,0,18,2,6,0,A,0,0,3,4,C0,23,5,6,B4,DE,E,6E,7,2,8,2,5B,8D,
где:
FF,3 – константы
CO,21 –LCP
3 - Не подтверждение конфигурации
3 – ID такойже как и в запросе
0,18 - длина поля ”информация”
2,6,0,A,0,0, - не использовать параметр, т.к. значение совпадает с предложенным сервером. Но если параметр не используется, то берётся значение по умолчанию. Т.е. все первых 32 знака проходят через ESC.
3,4,C0,23,- я посылаю отвержение параметра, но т.к. тип протокола С023(PAP) не совпадает с предложенным сервером С223(CHAP) то сервер должен принять новое значение.
6,B4,DE,E,6E,- не использовать ”магическое число», я посылаю такое же число, как и в запросе сервера, следовательно, сервер должен думать, что параметр отвержен.
7,2, - сжатие протокола не использовать. Вообще, какой то бредовый параметр. Я бы и хотел его использовать, но оказывается его нельзя использовать для LCP пакетов. Тогда зачем он нужен? Что то я не пойму.
8,2, - не использовать сжатие полей поля адреса и управления
5B,8D – последний байт в этой последовательности – это старший байт рассчитанной CRC.
Вобщем, посылаю этот пакет. В ответ сервер мне присылает:

FF,3,C0,21,1,5,0,E,2,6,0,A,0,0,3,4,C0,23,47,5B,
Где:

FF,3 – константы
CO,21 –LCP
1 - Запрос конфигурации
5 – ID. Почему не 4? Куда он потерялся? Ведь должен быть простояй инкремент?
0,E - длина поля ”информация”
2,6,0,A,0,0, - ПОЧЕМУ ОСТАЛСЯ ЭТОТ ПАРАМЕТР???????
3,4,C0,23 - Пфууу... Хоть тут сервер, догадался что делаь.

Ответьте на вышестоящие вопросы. Что я делаю не так. Я примерно описал ход моих мыслей – укажите где вы нашли ошибку.
Спасибо.