Свой стек 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

[edo]

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

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

[Spider]

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

+1

[Beginning]

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

[dch]

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

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

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

[readt]

Что я делаю не так? Через CRC надо пропускать байты уже преобразованные через 7D, или абсолютно каждый байт между ~~?
Если у кого есть исxодники PPP, можете помочь страждущему?
P.S. Т.к. есть большое желание узнать, как вся эта кухня работает, не предлагать взять готовый стек PPP и TCP/IP

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

[Beginning]

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

[Beginning]

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

Код

long x;
char *p;
1)
    x=(long)p[0]<<24;
    x+=(long)p[1]<<16;
    x+=(shot)p[2]<<8;
    x+=p[3];
2)
x=p[0];
for( char i=1; i<4; i++)
{
    x<<8;
    x+=p[i]
}

[vesago]

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

[etoja]

Можно так:

long x;
char *p;

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

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

[Baser]

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

Код

long x;
char *p;
x = (long)p[0]<<24 | (long)p[1]<<16 | (long)p[2]<<8 | (long)p[3];

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

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

[Beginning]

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

Все зависит от того, насколько применяемый компилятор обучен "догадываться" что вы хотите

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

[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 - Пфууу... Хоть тут сервер, догадался что делаь.

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

[Beginning]

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

[west329_]

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

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

Код

...
...
...
if ((Rx_Tx_buf [12] == 0x23) && (Rx_Tx_buf [11] == 0xC2))
{
Rx_Tx_buf[5] = NAK;
                                                                
Rx_Tx_buf[8] -= 1; //correct len  PACK
                                                                
Rx_Tx_buf[10] -= 1; //coorect len PARAM
Rx_Tx_buf[11] = 0xC0; //I wont PAP protocol
..
..
..

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

Сообщение отредактировал west329_ - Oct 10 2008, 15:54

[Beginning]

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

Прикрепленные файлы

 App.rar ( 5.81 килобайт ) Кол-во скачиваний: 59

 

[west329_]

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

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

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

Код

FF03 C021 01 03 0019 0206000A0000 0702 0802 0506AEA88890 0305C22305 887A

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

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

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

Код

FF03 C021 02 03 0008 0304C023 26FE

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

Код

FF03 C021 01 03 0018 0206000A0000 0702 0802 0506D85BBC5C 0304C023 A797

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

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

Код

FF03 C021 04 03 0014 050600000000 0206000A0000 0702 0802 701A

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

4) присылает

Код

FF03 C021 01 05 0008 0304C023 3B2C

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

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

Сообщение отредактировал west329_ - Oct 13 2008, 08:48

[lolful]

...
Мне не нужны все предложенные настройки. Вместо протокола CHAP нужен PAP.
Следуя алгоритму, я посылаю пакет NAK. Что написано про него в описании:
Пакет LCP типа Configure-Nak используется для сигнализации о том, что по крайней мере один из параметров, заявленных в пакете Configure-Request, не принят сервером РРР. При этом сервер должен указать, какой именно параметр не принят, и предложить альтернативное значение этого параметра в поле Опции этого пакета....

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

[Beginning]

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

[vesago]

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

[Beginning]

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

Вообщем стадия согласования параметров прохожу удачно. Дале по протоколу 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
Вобщем посылаю это, и ничего. Сервер ничего не отвечает. Что не по протоколу?

[vesago]

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

[Beginning]

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

[vesago]

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

Прикрепленные файлы

 _____1.rar ( 20.56 килобайт ) Кол-во скачиваний: 99

 

[Beginning]

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

[vesago]

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

[Beginning]

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

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

[lolful]

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

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

Сообщение отредактировал lolful - Oct 14 2008, 06:42

[vesago]

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

[lolful]

Моя логика была следующей: раз этот пакет - мой запрос, то и id я должен выдовать свой.

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

Сообщение отредактировал lolful - Oct 14 2008, 06:46

[Beginning]

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

Код

Serial port COM1 opened
Инициализаци{FF}--------------------
at&f
at&f
OK
ate0
ate0
OK
AT+CPIN?

+CPIN: READY

OK
Ожидание регистрации   в GSM сети...
AT+CREG?

+CREG: 0,1

OK
Регистраци{FF} успешна.-------------------
at+cgdcont?

OK
AT+CGDCONT=1,"IP","wap.velcom.by"

OK
ATD*99***1#

CONNECT
~{FF}}#А!}!}#} }9}"}&} }*} } }'}"}(}"}%}&0ТЎА}#}%В#}%oV~
Тело:FF,3,C0,21,1,3,0,19,2,6,0,A,0,0,7,2,8,2,5,6,30,D2,A1,C0,3,5,C2,23,5,6F,56,
Сервер предложил(LCP ID:3):
Async Control Character Map:A0000
Протокол аутентификации:C223
Параметр "магическое число":30D2A1C0
Cжати{FF} пол{FF} протокола
Cжати{FF} полей адреса и управлени{FF}

тело OUT: FF,3,C0,21,4,3,0,18,2,6,0,A,0,0,3,4,C0,23,5,6,30,D2,A1,C0,7,2,8,2,7,5F,~{FF}}#А!}$}#} }8}"}&} }*} } }#}$А#}%}&0ТЎА}'}"}(}"}'_~~{FF}}#А!}!}%} }(}#}$А#;,~~{FF}}#А!}!}%} }(}#}$А#;,~
Тело:FF,3,C0,21,1,5,0,8,3,4,C0,23,3B,2C,
Сервер предложил(LCP ID:5):
Протокол аутентификации:C023

---CONFIG OK---

тело OUT:FF,3,C0,21,2,5,0,8,3,4,C0,23,EB,A6,
PPP login:
PPP passward:

тело OUT:FF,3,C0,23,1,5,0,6,0,0,91,4,

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

[vesago]

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

[Beginning]

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

Код

Serial port COM1 opened
at+cgdcont?

OK
AT+CGDCONT=1,"IP","wap.velcom.by"

OK
ATD*99***1#

CONNECT
~{FF}}#А!}!}#} }9}"}&} }*} } }'}"}(}"}%}&Ї$/}1}#}%В#}%ъд~
<--GSM:FF,3,C0,21,1,3,0,19,2,6,0,A,0,0,7,2,8,2,5,6,AF,24,2F,11,3,5,C2,23,5,FA,E4,

-->GSM:FF,3,C0,21,4,3,0,18,2,6,0,A,0,0,3,4,C0,23,5,6,AF,24,2F,11,7,2,8,2,C0,79,
~{FF}}#А!}$}#} }8}"}&} }*} } }#}$А#}%}&Ї$/}1}'}"}(}"Аy~~{FF}}#А!}!}%} }(}#}$А#;,~
<--GSM:FF,3,C0,21,1,5,0,8,3,4,C0,23,3B,2C,

---CONFIG OK---

-->GSM:FF,3,C0,21,2,5,0,8,3,4,C0,23,EB,A6,
~{FF}}#А!}"}%} }(}#}$А#л¦~
PPP login:
PPP passward:

-->GSM:FF,3,C0,23,1,1,0,6,0,0,81,29,
~{FF}}#А#}!}!} }&} } Ѓ)~
PPP login:
PPP passward:

-->GSM:FF,3,C0,23,1,1,0,6,0,0,81,29,
~{FF}}#А#}!}!} }&} } Ѓ)~
PPP login:
PPP passward:

-->GSM:FF,3,C0,23,1,1,0,6,0,0,81,29,
~{FF}}#А#}!}!} }&} } Ѓ)~
PPP login:
PPP passward:

-->GSM:FF,3,C0,23,1,1,0,6,0,0,81,29,
~{FF}}#А#}!}!} }&} } Ѓ)~
PPP login:
PPP passward:

-->GSM:FF,3,C0,23,1,1,0,6,0,0,81,29,
~{FF}}#А#}!}!} }&} } Ѓ)~~{FF}}#А!}%}%} }$\¤~~{FF}}#А!}%}%} }$\¤~
NO CARRIER

Что не так?

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

[west329_]

после 18.00

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

Сообщение отредактировал west329_ - Oct 14 2008, 12:23

[Beginning]

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

[vesago]

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

[Beginning]

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

[lolful]

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

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

[Beginning]

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

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

[Beginning]

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

Код

7E,FF,3,C0,21,1,0,0,17,2,6,0,0,0,0,5,6,20,A4,5,5D,7,2,8,2,D,3,6,F7,D9,7E,

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

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

Код

7E,FF,3,C0,21,4,0,0,7,D,3,6,AD,36,7E,

[Beginning]

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

Код

7E,C0,21,0C,03,00,12,20,A4,05,5D,4D,53,52,41,53,56,35,2E,31,30,42,C4,7E,

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

Код

MSRASV5.10

Затем комп сразу посылает:

7E,C0,21,0C,04,00,19,20,A4,05,5D,4D,53,52,41,53,2D,30,2D,44,45,56,45,4C,4F,50,45
,52,5F,8E,7E,

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

Код

MSRAS-0-DEVELOPER_

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

[west329_]

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

[west329_]

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

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

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

[Beginning]

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

[west329_]

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

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

[Beginning]

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

[lolful]

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

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

Сообщение отредактировал lolful - Oct 20 2008, 11:59

[Beginning]

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


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

[Огурцов]

Я не считаю PPP протоколом

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

[Beginning]

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

[Beginning]

Уменье и труд всё перетрут!
Удалось, неимоверными усилияи сдвинуть гору. Я получил IP....
Полёт продолжается. Теперь можно слать TCP дейтограммы.

[west329_]

Уменье и труд всё перетрут!
Удалось, неимоверными усилияи сдвинуть гору. Я получил IP....
Полёт продолжается. Теперь можно слать TCP дейтограммы.

И гдеже гвоздь был ?

Советую для начало написать ICMP и попинговать для уверенности например гугл или рамблер а потом уже на ТСП переходить, всёравно писать его прийдётся .

Как планируете реализоват ТСП, сокет писать будитете или напрямую в лоб ?

Сообщение отредактировал west329_ - Oct 23 2008, 07:24

[Beginning]

Все проблемы были связанны как всегда с недостатком информации.
Вначале меня остановило следующее: когда на LCP мне модем слал конфигуровачную информацию, и я отвечал, мол ОК, инфа подходит, и я думал что канал согласован. Ан нет! Оказалось, что я должен послать такой же пакет модему, и он должен мне тоже дать согласие.
Т.е. можно сделать вывод, что можно настроить PPP соединение с разными опциями на отправку и приём. Но зачем?
Вторая проблема была связана с паролями. На сайтах даётся пароль и логин. Как оказалось можно ввести любой пароль для PPP сессии, и при этом сервер ответит, мол пароль принят. Но когда сделаешь запрос IP, то PPP мгновенно разрывается. Походу это сделано, для получения фиксированных IP, т.е. если угадаешь логин, пароль и ip адрес, то добро пожаловать в интет за халявные денюшки.

[edo]

все реализации ppp для gprs, которые мне попадались, работают с любым логином/паролем (или вообще без авторизации).

а для фиксированных ip обычно используется другой apn - но халявой там никак не пахнет

[Beginning]

То что пароль надо, этот факт одназначный. Даже в винде если не указать пароль, то при конекте пишет:"Удалённый хост разорвал PPP соединение"

[lolful]

И гдеже гвоздь был ?

Советую для начало написать ICMP и попинговать для уверенности например гугл или рамблер а потом уже на ТСП переходить, всёравно писать его прийдётся .

Как планируете реализоват ТСП, сокет писать будитете или напрямую в лоб ?

Это верно. Я так и поступил, что и Beginning'у советую.

[KGB]

привет всем..
я в гсм теме недаво... и поэтому мне не всё понятно..
из этой темы я понял что РРР стек бывает софтовый и аппаратный, как в SIM300, правельно?
шас веду пару проектов на эту тему...
один из которых для украинских коллег. (результат будет обнародован)
так вот.. имеем одну такую вот связку..
спутниковый приёмник+пик18ф1320+сименс 65-75
сняв логи приработе устройства между пиком и телефоном...
AT+FCLASS=0
AT+FCLASS=0

OK
ATS7=60\Q0
ATS7=60\Q0

OK
AT+CGDCONT=1,"IP","internet.volga"
AT+CGDCONT=1,"IP","internet.volga"

OK
ATD*99***1#
ATD*99***1#

CONNECT
~я}#А!}!}#} }9}"}&} }*} } }'}"}(}"}%}&\@Ыѓ}#}%В#}%Xj~~я}#А!}!} } }(}#}$А#�Ь~~я}#А!}"} } }(}#}$А#HV~~я}#А!}!}#} }8}"}&} }*} } }'}"}(}"}%}&\@Ыѓ}#}$А#{‡~~я}#А!}$}#} }4}%}&} } } } }"}&} }*} } }'}"}(}"p}:~~я}#А!}!}%} }(}#}$А#;,~~я}#А!}"}%} }(}#}$А#л¦~~я}#А#}!}%} }4}'megafon}'megafoniЮ~~я}#
и так далее....
понял чтоэто
софтовый РРР, правельно????

так вот чтоб разобраться в протаколе обмена этого устройства с серваком надо эту лабуду
привести в читабельный вид... КАК ЭТО СДЕЛАТЬ??????

[west329_]

привет всем..
я в гсм теме недаво... и поэтому мне не всё понятно..
из этой темы я понял что РРР стек бывает софтовый и аппаратный, как в SIM300, правельно?
шас веду пару проектов на эту тему...
один из которых для украинских коллег. (результат будет обнародован)
так вот.. имеем одну такую вот связку..
спутниковый приёмник+пик18ф1320+сименс 65-75
сняв логи приработе устройства между пиком и телефоном...
AT+FCLASS=0
AT+FCLASS=0

OK
ATS7=60\Q0
ATS7=60\Q0

OK
AT+CGDCONT=1,"IP","internet.volga"
AT+CGDCONT=1,"IP","internet.volga"

OK
ATD*99***1#
ATD*99***1#

CONNECT
~я}#А!}!}#} }9}"}&} }*} } }'}"}(}"}%}&\@Ыѓ}#}%В#}%Xj~~я}#А!}!} } }(}#}$А#�Ь~~я}#А!}"} } }(}#}$А#HV~~я}#А!}!}#} }8}"}&} }*} } }'}"}(}"}%}&\@Ыѓ}#}$А#{‡~~я}#А!}$}#} }4}%}&} } } } }"}&} }*} } }'}"}(}"p}:~~я}#А!}!}%} }(}#}$А#;,~~я}#А!}"}%} }(}#}$А#л¦~~я}#А#}!}%} }4}'megafon}'megafoniЮ~~я}#
и так далее....
понял чтоэто
софтовый РРР, правельно????

так вот чтоб разобраться в протаколе обмена этого устройства с серваком надо эту лабуду
привести в читабельный вид... КАК ЭТО СДЕЛАТЬ??????

То что вы отлогировали это только инициализация РРР, и так сказать вершина айсберга. Почитайте сначало про протоколы и команды AT, PPP, IP, UDP для начала ну и ТСР если, не передумаете после этого.
Слышал гдето, что то, что вы пытаетесь повторить использует криптоалгоритм AES . Выводы делайте сами.

[dch]

протокол 2го уровн

транспортный может лежать под любым это как сделать :-{h

[MiDV]

Здравствуйте.
Возникла проблема с соединением PPP.
Тему я поднял в разделе помощь начинающему, но она перекликается с этой темой.
Проблема такая - есть модем, Quectel M10. При попытке коннектиться с контроллера он отказывается выдавать IP адрес.
Но в то же время при подключении вместо контроллера компа с установленным стандартным драйвером - коннектится.
Обмен как с участием контроллера, так и с участием компа я выложил.
Сылка на тему
Если кто сталкивался с таким, или если кто разбирается - помогите, пожалуйста.