Долго искал, где создать тему, так и не нашёл. Разместил здесь, т.к. в конечном счёте, 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

http://electronix.ru/forum/index.php?showtopic=51447

ps: меня всегда удивляет - а почему не подглядеть интересующие моменты в linux/freebsd/...? есть целая кучка опенсорсных реализаций ppp.

+1

Не работал с Linux. Где искать source не представляю. На сайтах про Linux, описание такое, что не работав с этой OS, трудно понять про что вообще идёт речь.

можно посмотреть в дистрибутиве uclinux:

http://www.uclinux.org/pub/uClinux/dist/

качаете архив весь, разворачиваете, каталоге users лежит pppd. Часть поддержка находится в pppd
часть в ядре, ядра также находятся в верхнем каталоге как развернете.

Лучше привести Hex dump пакета до и после удаления префиксации. Тогда можно будет определиться где допущена ошибка.
Для РРР контрольная сумма охватывает весь пакет.

Спасибо всем ответившим. Как всегда дело оказалась в мелочи, на которую, во всех описаниях PPP, авторы посчитали не обращать внимание. Оставим это на их совести.
В общем, данные на CRC надо было подавать в зеркальном виде. Т.е. первый бит в байте должен быть последним и наоборот. Это походу связано с видом физической передачи данных в Ethernet, где как раз, так и делается. Возможно, отсюда корни растут, может я и ошибаюсь.
В теме “ppp на Siemens MC35i, помогите с CRC алгоритмом” добрые люди подсказали, как эту “зеркаляцию” встроить в сам алгоритм расчёта CRC, за что им отдельное спасибо.

Вопрос может показаться кому то несколько смешным, однако всё же, ИМХО, имеет право на существование.
В процессе кодописания, одна из множества самых распространённых используемых операций это копирование переменной из памяти( стек, буфер и т.д.) в локальную переменную. В 99% случаев - это регистр. Если переменная char, то в принципе всё однозначно, а если long?
Так вот, какой минимальный код будет реализовывать эту функцию. На входе имеем номер регистра и адрес памяти первого актета long. Для определённости, я работаю на платформе ARM9. Впрочем для С, это особой роли не играет. У меня в голову приходит только два варианта:

Имхо приятнее пользовать какую memcpy из стандартной библиотеки. Вообще библиотека замечательная вещь. Она избавит вас от лишнего гемора во многих случаях.

Можно так:

long x;
char *p;

x=(long)*(p++);
x <<= 8; x += *(p++);
x <<= 8; x += *(p++);
x <<= 8; x += *p;

Здесь отсутствуют накладные расходы на организацию цикла for и на вызов функции memcpy.

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

при этом компилер просто загрузит нужные байты в нужное место без оверхеда.

з.ы. а вообще-то это не вопрос для форума по сотовой связи. А в разделах по программированию на МК это было много раз...

Этот вопрос я адресовал в эту тему, потому что он возник во время писания PPP стека. Дабы не плодить темы написал здесь.

В точку! Я это и имел ввиду, только не смог выразить.

Помогите решить проблему.
Сразу после 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 - Пфууу... Хоть тут сервер, догадался что делаь.

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

Походу Async Control Character Map обязательный параметр.
Ну что ж, я его проинитил 0xFFFFFFFF и всё OK.

отвергай сначало все кроме CHAP,
потом подправляеш входящий пакет и отсылаеш его ему обратно



p.s. на чём пишеш, камень какой ? можна исходники посмотреть ?

Пишу под платформу ARM9. Компилятор RVDS. Впрочем на С нет большой разницы, под какую платформу эти исходники потом компилировать. Разве что, общение с портом надо будет подправлять в зависимости от платформы и среды. У кого драйвер, у кого прерывание.
Цель проекта: детально разобратся с PPP, TCP/IP стеком, сделать полноценную рабочую версию, что называется, не хуже чем у других. Но сколько бы я не писал, постоянно получается, какая-то ГРОМОЗДКАЯ “писанина”, хоть и рабочая, но ОЧЕНЬ НЕ ОПТИМАЛЬНАЯ.
Я сейчас реализовал приём PPP фрэймов, и протокол LCP.
Выкладываю исходник. Предлагаю общественным путём доработать их. Голая критика, без своих ВАРИАНТОВ, не ПРИВЕТСТВУЕТСЯ, ибо не несёт ни какой ценности.
To west329_:
Что вы имели в виду под фразой:”потом подправляеш входящий пакет и отсылаеш его ему обратно”. В виде чего отсылать и что подправлять? Мне например нужен протокол PAP. Отсылать пакет ASK или что другое?

Так как я работаю с 8 битным контроллером то у меня нету разделения на RX TX буффера, и для экономии я корректирую входящий пакет и отправляю ему обратно.

Получается такой алгоритм:
1)
Присылает сервер строку


0305C22305 тут CHAP, требуем РAP, я делаю так

-коректируем Тип пакета, Configure-Request
-корекируем Длина поля «Информация пакета»;
-данные пишу FF03 C021 01 00 0008 0304C023 98DC
-отпавляем серверу

2) он присылает с огласие


3) опять присылает

отвергем всё кроме РАР

-коректируем Тип пакета, Configure-Request
-корекируем Длина поля «Информация пакета»;
-данные пишу

-отпавляем серверу

4) присылает

если ещё интересно напишу ещё ?

P.S.
Сам хочу реализовать TCP протокол, но пока ещё не выходит, с удовольствим поддержу автора.

Ключевое слово сдесь сервер. Вы как-бы не имеете право посылать NAK, т.к. являетесь ведомым в этой сессии. Чтобы отвергнуть предложенные сервером настройки надо послать ему пакет Config-Reject.

Спасибо за уточнение. Config-Reject - действительно прокатыает сразу. Мне сбили с толку неоднократные неточности в русских переводах документации на PPP.

Кстати на фтп есть замечательная книжка TCP-IP Lean--Web Servers for Embedded Systems и к ней прилагается чудесный код PPP, который при небольшой подпилке хорошо ложится в проект. Там же есть TCP/IP, но уже похуже.

Спасибо. Качаю.

Вообщем стадия согласования параметров прохожу удачно. Дале по протоколу PAP я должен передать серверу login и passward. Насколько я понял в GPRS нету login и passward PPP коннекта. Поэтому посылаю строку:
FF,3,C0,23,1,2,0,6,0,0,56,24
Ff,3 – константы
С023 – PAP
1 – reqwest
2 – это id моих посылаемых пакетов. Насколько я понял, начальное значение могу взять любое, а потом инкрементировать? Или как-то подругому.
6 –длина
0 – pasward 0
0 – login 0
56,24 – CRC
Вобщем посылаю это, и ничего. Сервер ничего не отвечает. Что не по протоколу?

Мне кажется, что что-то там нужно вводить логин и пароль. Посомтрите у опсоса информацию о подключении к мобильному интеренету. Открою одну тайну. Все это дело вы можете отладить на компьютере, создавая соединение по последователному порту. Таким макаром также можно соединить пару виртуальных компортов и посмотреть в снифере как гоняются данные и согласуются параметры.

Насколько я понял есть пароль к PPP соединению, а есть к TCP/IP или как его там, короче тот что к шлюзу на официальных сайтах указан. У меня например "wap","wap". Но это пока предположение, т.к. я не приступил к изученю TCP. В любом случае если пароль неправильный, так хоть о данном факте должен сообщить сервер. А тут вообще ничего.
Что касается отладки через комп. Тоже вариант. Но по ниму надо было идти изначально. Но стоя в начали пути на распути, я выбрал вариант с изучением документации, реализации на контроллере и анализом трафика. Поэтому переключение на первый вариант, сейчас будет накладно.

Если не читали ранее, ознакомьтесь. Там на пальцах расписано. Про комп я имел ввиду, что можно к железке подсоединить вместо модема и сервера опсоса и отладить все основные моменты. Как на уровне ппп так и тсп/ип.

Да этот документ у меня есть. Что сказать. В этом документе описан лишь необходимый минимум и он не описывает множество мелочей (а в них как известно скрывается дьявол), и нестандартных ситуаций. К тому же он изабилует множество элементарных ошибок или опечаток, от чего впрочем не легче.
Запрос PAP у меня точно такой же, как и автора этого документа, разве что подазрение на id падает. У автора не сказанно какой id брать надо. (эта мелочь он посчитал не нужной)
Моя логика была следующей: раз этот пакет - мой запрос, то и id я должен выдовать свой. Хорошу попробую присвоить id последнего пакета сервера и посмотрю, что получится.

Документ этот действительно не на все случаи расчитан. Создайте на компе последовательное соединение двух виртуальных компортов и посмотрите снифером как у них идет соединение ппп. Можно с паролем, можно без. Много станет ясно на каком этапе затык.

Послал:
FF,3,C0,23,1,5,0,6,0,0,91,4,

Получилась точная копия как в документе 1.doc Т.к. id=5 и CRC совпало.
Так вот, "теже яйца вид слева".

Копайте в сторону настройки параметров GPRS (+cgatt, +cgdcont и т.п.) и телефона дозвона (я пишу так atd *99***1#). Мне кажется, что проблема в этом.

PS Какой оператор?

Возможно вы перед этим не согласовали соответсвующий протокол авторизации или еще какой параметр. Вот сервер и ждет. Чтобы разобраться - возьмите вставьте сим карту в телефон, телефон подсоедините к компу, натравите сниффер на ком порт и создав успешное модемное соединение, выйдите в интернет. Разберите данные в сниффере и если ваше железо повторит ту же последовательность действий, то проблем не будет. А так можно долго гадать почему да как.

Логика абсолютно правильная . Проблема точно не в этом.

Чтобы не описывать каждый свой шаг, приведу текст отладочной информации который я выкидываю в порт. (в драйвер портов внедрён snifer - выводится весь поток на модем и с модема, плюс моя отладочная информация):


Скачал TCP-IP Lean--Web Servers for Embedded Systems.
Там есть проект для PIC18. Последний раз с PIC работал лет 7 назад. Работал, если не изменяет память с MPLAB.
Вопрос: какая среда используется для этого проекта? Есть файл с расширением .prj

Там наверное использован хайтэч + мплаб. Но вам это не нужно. Там все написно на сях. Портируйте в свой проект только то что нужно.

Блин! Почему не работает? Модем MC55. Подправил snif+debag_inf для наглядности:

Что не так?

To west329_:
Не могли бы вы прислать свои логи PAP?

после 18.00

п.с. Может настройки провайдера глючат, попробуйте с другой симкой и провайдером. У меня такое не раз было на Лайфе

Народ, кто подскажет программу, которую можно просто на COM натравить, на котором модем GPRS висит, что бы она в INET вышла. А то я что-то не нашёл. Ставлю обычный драйвер стандартного модема, так он мне аппаратную ошибку выдаёт. Видимо не заточен под GPRS.

Видно не знает стандартный драйвер особенности вашего аппарата. Качните в интеренете дрова под свой модем/телефон. Допустим тут

Искал инфу. Наткнулся на это:
http://www.xakep.ru/post/37720/default.asp
Я плакал.

У меня Windows XP SP2. Я просто добавил новый модем, настроил соединение и все заработало. Никаких драйверов скачивать не пришлось. Модем Siemens mc35i.

А какой именно модем вы добавили??????

У меня вообще глюки, капец какие. Мало того, что после согласавания параметров, модем вступает в ступор, и не отвечает ни на какие запросы PAP и IPCP, а через 1 минуту как ни в чём небывало, присылает мне Code-Reject, но впрочем я это описал выше, так ещё и винда такие фокусы выдаёт!
Установил драйвер на модем. Простой .inf. Делаю подключение. Смотрю в PortMonitor уходят запросы AT, а в порт физически не поступают. Т.е. просераются гдето между драйвером и микрухой порта, или ещё где. Пипец какойто.

В общем и целом, удолось подключить модем к компу и выйти в интернет. При этом удалось удачно заснифить весь трафик. И сразу посыпались сюрпризы. Как оказалось, комп сразу берёт инициативу на себя и начинает предлогать настройки модему. Вот первая его посылка:

Кто знает, что за параметр: D,3,6? Нигде в referenc нет описания?

Кстати, не только я не знаю что за параметр, но и модем тоже. На что он благополучно фыркнул реджектом:

Обнаружил что сразу после согласования параметров, комп посылает модему следующее:

Что за тип 0x0С? Если приглядется то в теле есть строка
Затем комп сразу посылает:

В теле содержится:

После этого, комп посылает пороль по PAP, и модем отвечает аском. Что это за фигня?

не обращай внимая, это винда, надо использовать стандартные АТ
ATE
ATH
AT+FCLASS=0
ATS7=60\Q0
AT+CGDCONT=1,\x22IP\x22,\x22internet\x22\x0D\x0A" - точка доступа
ATD*99***1# -- для сименс

Ув. не подскажите, пока автор молчит, задам вопросик.
Разбираюсь с передачей пакетов в режиме ЖПРС через РРР сесию, как протокол верхнего уровня стоит UDP,

Собственно вопрос такоой, обём данных которые упаковываются в UDP на постоянный и находится в предел от 100 до 180 байт, играет роль четное или не четное количество байт, надо ли както это исправлять.

Получается что часть пакетов не выходит за пределы телефона, не слышно характерного звука в колонке, а часть пакетов процентов 30 проходит нормально, и проблема не со стороны сервера уже проверяли неоднократно, уже незнаю на что грешить ???

Насколько я помню, но GPRS поддерживает только IP, или это только для sim300?

IP это транспортный протокол, на него ложатся UDP или TCP, до него идёт РРР скорее всего только его поддерживает GPRS.

Sorry, ступил. Не внимательно читаю.
Кстати,насчёт PPP, моё ИМХО, это не протокол, а стек. Называя его протоколом, мы его ставим на один уровень, например с LCP, это запутывает и это неправильно. PPP - это общее название набора протоколов таких как NCP, PAP, CHAP и т.д. Вообще в самом низу лежит HDLC, а от PPP в нём только цифра 3 - стек протоколов PPP. Вобщем без пол-литры не разберёшся

PPP по-моему протокол 2го уровня, ниже него только физ. уровень (UART?) в модели OSI. А протоколы типа LCP, IPCP, IP и т.п. - протоколы более высокого уровня, т.е. включаются в поле "данные" протокола PPP.

А слово стек преводиться как стопка. То есть стек в Вашем случае будет UART/PPP/IP/UDP. Ящитаю.

Из Википедии:
Сетево́й протоко́л - набор правил, позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами. Разные протоколы зачастую описывают лишь разные стороны одного типа связи; взятые вместе, они образуют стек протоколов.


Я не считаю PPP протоколом, потому что, он не описывает конкретные “байтовые операции” и соотношение состояний между ними. Он только подразумевает последовательность включённых в него протоколов (LCP,IPCP и т.д. ) PPP не определяет не одного байтового значения, разве что в протоколе HDLC есть поле (1 байт) – тип протокола, так вот значение 3 там соответствует PPP, на этом байтовые отношения в PPP заканчиваются. Т.е. PPP – это стек. А стек подразумевает не только вертикальное отношение протоколов, но и горизонтальное разветвление.
P.S. Это моё ИМХО. Выслушаю различные точки зрения.

Не надо придумывать, все уже давным-давно придумали: RFC1661 - The Point-to-Point Protocol

А по существу?