Доброго здравия, уважаемые форумчане.

Подскажите, правильно ли я понимаю, что связь модуля с базовой станцией в режимах GPRS, EDGE, WCDMA, HSPA всегда осуществляется по протоколу PPP и других вариантов не существует. То есть модули со встроенным TCP/IP стеком делают это тихо и незаметно, а для модулей без стека нужно реализовывать не только TCP/IP, но и PPP.

Не пинайте сильно, новичок я в этой теме.

Ничего не понимаю в TCP/IP, но GPRS связь работает через APN.

Если оператор обеспечит вам VPN канал - то для вас это, как я понимаю, будет обычной локальной сетью без выхода в интернет.

Я не про VPN . Я про обычное соединение с интернет через любой сотовый модуль.

По протоколу PPP осуществляется не связь модуля с базой, а связь пользовательского софта с ядром модуля. Если в модуле реализована поддержка PPP, то считайте это "прослойкой" между следующим уровнем софта и ядром. С ядром устанавливается PPP, а далее выдаются/принимаются данные данные с помощью АТ-команд и режима данных.
Если такой поддержки нет (например, мобильные телефоны), и подключение осуществляется с помощью ATD***1#, то, отправив CONNECT, ядро представляет РРР соединение, и клиент должен следовать протоколу.
На самом деле, ничего сложного тут нет, просто народ обычно ленится. Надо отработать фазу LCP (согласовать параметры), PAP/CHAP (логин-пароль) и IPCP (получить IP). Для GSM все стадии шаблонные, и легко реализуются с помощью простых парсеров и отсылки паттернов. Для CDMA сложнее, требуется CHAP и есть другие ньюансы. После инициализации необходимо вручную формировать пакет: данные вкладывать в UDP или TCP, затем в IP, затем в PPP (т.е. дописывать заголовки, считать контрольные суммы, вести счетчики ACK/SEQ, убирать 7D и т.п.).

В принципе, сейчас это имеет лишь образовательную ценность, т.к. практически во всех модулях есть готовые стеки. Но если есть академический интерес, могу скинуть ссылку на свой проект почти 10-летней давности, где на ассемблере PIC в 8K ROM и 256 байт RAM реализовано все описанное для линейки телефонов Siemens с TCP-подключением к удаленному серверу и даже слоем шифрования согласно протоколу верхнего уровня. Но если Вы найдете время и желание реализовать это самостоятельно, то выйдете на качественно новый уровень: разберетесь в тонкостях работы интернет, ТСР-стека (в т.ч. и в общих ОС) и избавитесь от массы заблуждений, характерных для высокоуровневых разработчиков.

GeGeL, спасибо за консультацию. Задача как раз и состоит в том чтобы реализовать все эти протоколы своими силами, поэтому от ссылки не откажусь. Но данные передавать надо в режиме HSPA, а в качестве модулей будут использованы SIM5350 или нечто подобное без встроенного стека. IP у обоих будут "белые" и статические. И вот тут есть один абсолютно непонятный для меня момент. Насколько я знаю ATD*99# это в итоге поднятие GPRS. А как получить что-нибудь из HSPA ? Там туча категорий, которые отличаются скоростями. Ну, допустим, базовые станции на обоих концах готовы выдавать/принимать пакеты на больших скоростях, как в этом случае нужно конфигурировать сами модули и устанавливать подключения к интернет ?
У меня такое подозрение (после наблюдений за модемом HUAWEI E3131), что станция и модем сами скорости разруливают и от управляющего контроллера (компьютера) ничего не зависит.

Я в свое время тоже баловался PPP. Отлаживал через соединение с компьютером по COM порту. Реализовал обработку ICMP и TCP. До конечного устройства дело не дошло. Пробовал подключать модем к терминалке, набирал ATD*99# и при соединении начинали переть PPP пакеты.

Ну и ещё вопросик до кучи. Между модулем и станцией на канальном уровне ведь тоже протокол PPP ? Если нет, то в чём тогда смысл обмена данными по PPP только между пользовательским софтом и ядром модуля ?

GeGel, я выше писал, что не откажусь от ссылки. Вы, наверное, не заметили. Буду очень признателен.

Извините, пропустил нить обсуждения в теме.



На канальном уровне свои протоколы, они реализуются чипсетом на уровне GSM-стека и, как правило, недоступны следующему уровню софта. Наверное, РРР был выбран из-за наличия готовых клиентов в ОС: изначально телефон подключался к РС в качестве модема через COM-порт, на РС создавалось удаленное соединение и т.о. осуществлялось подключение РС к Интернет.



ATD*99# это виртуальный звонок на виртуальный номер, и знаки после ATD определяют параметры устанавливаемого соединения и передают их в чипсет. Дальше модуля номер не передается, звонка, как такового, тоже не выполняется, модуль устанавливает дата-соединение с сетью, самостоятельно согласуя его параметры. Кроме того, с данного софт. уровня невозможно управлять канальным протоколом (классом GSPRS, EDGE или HSPA). Но, возможно, производитель модуля представляет определенные АТ-команды для этого.

Старый проект, реализующий PPP, доступен на моем сайте http://torfone.org/download/cambr01xx.zip (также прилепил к посту для удобства), когда-то это использовалось для кардшаринга в декодировании спутникового ТВ и код имел значительную коммерческую ценность, но сейчас - только академическую. Используется PIC18F1320 + ENC28J60, девайс представляет мост между RS232-интерфейсом тюнера и удаленным сервером, подключаясь к последнему по стандартному протоколу на основе TCP с аутентификацией и tDES-шифрованием (согласно спецификации). Соединение возможно через Ethernet и резервируется GPRS через линейку телефонов Siemens. Инициализация РРР жестко завязана на эту модель телефона и работает по паттернам, например, для SIM300 код уже был другой (если интересно, пороюсь в архивах, найду). По уму надо подключить ваш модуль к Win32 PC через COM-порт и отлогировать процедуру поднятия соединения средствами Windows, а затем повторить все самостоятельно с использованием паттернов захваченных пакетов.

Кроме РРР, интерес в коде может вызвать рукописный TCP-стек + DHCP, DNS и библиотека для ENC28J60, но, опять же, все максимально урезано до необходимого под конкретную задачу, ничего лишнего: just work. Почти каждая ассемблерная команда комментирована на русском, надеюсь, будет полезно для обучения. Если будут конкретные вопросы, задавайте на форуме, чуть разбавим коммерческую ветку теорией

Вот до этого я как-то и не додумался. Спасибо огромное !!!
Ну а если бы ещё посоветовали, что для таких задач (на Ваш взгляд) лучше использовать в качестве логгера, было бы вообще здорово !

Когда-то по быстрому нацарапал как инструмент (в аттаче). Там есть глюки (зависает при переполнении, если идет "мусор" с порта), но в общем подойдет. Логирует в обоих направлениях, но надо спаять соответствующий нуль-модемный шнур с двумя отводами, и для логирования использовать отдельную РС с двумя ком-портами (лучше физическими, но можно и одинаковые USB-COM).
Вход в настройки - двойным кликом по строкам ввода данных, выход - по надписям COMa, b. При использовании USB-COM (PL3203, FT232 etc.) установите галки RTS и DTR.

Ну, и можно отлогировать порт софтово, установив какой-нибудь SerialPortMonitor, их много под Windows, но все в основном требуют таблэтку.

PS: перед разбором лога желательно почитать подробное описание РРР (соответствующие rfc или что-нибудь русскоязычное типа http://book.itep.ru/3/ppp_35.htm). Также добавил в аттач старый документ неизвестного мне автора, найденный в сети много лет назад.

В папке BOOKS/PIC/TCP-IP Lean -- Web Servers on PIC18 and Wi-Fi есть неплохой талмуд на эту тематику PPP Design, Implementation and Debugging 2nd Edition. Там же исходники приложены. Если Win32 сниффер - Free Serial Port Monitor. Если 64 бита - Eltima.Serial.Port.Monitor. Ну и для разбора TCP/IP - CommView.

Это где: на Microchip или на нашем ftp?

Я пользовал SoftPerfect Network Protocol Analyzer, весьма удобно. За 10 лет много нового софта появилось.
Вообще, есть все условия для обучения, но желания все меньше у народа. Я вот смотрю свой код в аттаче выше cambr01xx.zip\cambr01xx\FW\ca012drf.asm - сколько знаний туда было вложено. Но это дало понимание происходящего в деталях, и сейчас, лепя готовые чужие библиотеки, гораздо проще отлаживать и, тем более, делать нестандартные решения. Так что оно того стоило.

На ftp. Да, были времена ограниченных возможностей, когда производитель не баловал встроенным TCP/IP стэком, не подталкивал пользовать либы.

Уважаемые форумчане! Если я правильно понял-то AT командами модема можно установить соединение по протоколу PPP, далее необходимо формировать пакеты в формате этого протокола, соответственно парсить ответы и в результате этого диалога нами будет получен динамический IP-адрес. Ну а с передачей данных как? Я просмотрел документы по протоколу PPP(правда не во все вник) и не нашел там собственно кодограмм для отправки данных. Как отправить ну например UDP-пакет. Может кто подскажет или поделится ссылкой.

Допустим, имеются данные (до 512 байт).
Сначала формируете UDP-пакет, дописывая UDP-заголовок, см. тут:
http://book.itep.ru/4/44/udp_442.htm
UDP-контрольную сумму можете не считать, используйте 0.
Затем формируете IP-пакет, дописывая IP-заголовок, см. тут:
http://book.itep.ru/4/44/ip_441.htm
Надо считать IP контрольную сумму (16 bits modulo2).
Затем формируете ppp-пакет, см. тут:
http://book.itep.ru/3/ppp_35.htm
(в дописываете ppp-заголовок в начале, ppp crc16 в конце, выполняете 7D-преобразование
по всему пакету и обрамляете символами 7E).
Секрет: обычно несжатый заголовок и 7D-преобразование всех символов меньше 20 приемлемо, независимо
от согласования на этапе LCP).
В итоге оправляете в ком-порт побайтно полученный пакет (начинается и заканчивается 7E).

При получении ppp-пакета проводите обратное 7D-преобразование и экстрагируете непосредственно данные (обычно по фиксированному смещению).

alex-214, всё же обычно модуль все пакеты формирует за вас, можно обойтись простыми AT-командами.
Но если интересно формирование пакетов вручную - посмотрите здесь статью про формирование PPP GSM до этапа получения IP включительно, может поможет) Успехов!

Познавательная статья. Наверное, для полного понимания и возможности повторения программистом целесообразно добавить:
- алгоритм подсчета crc16;
- алгоритм 7D-преобразования;
- формат упаковки IP-пакетов в ррр.

Также неизбежно вызовет интерес формат IP- и UDP- пакета и, возможно, формат запроса/ответа на DNS. Но это уже тянет на цикл статей.

Хотите идею? введите незначительные особенности в ваши АТ-команды, и опубликуйте С-библиотеку для вашего модуля, включающую общие процедуры работы с сервером, конфигурирование, парсинг NMEA и т.п. Железо должно продаваться лучше.

GeGel, спасибо,
статья, конечно, ни в коем случае не претендует на полноту/абсолютную точность, писалась по результатам решения конкретной задачи,
если кому-нибудь ещё пригодится - хорошо)