реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> RL-TCPNet (PPP) подключение к 3G Telit [РЕШЕНО], Проблемы с PPP соединением
Sergiy26
сообщение Dec 24 2014, 23:56
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 28
Регистрация: 1-01-09
Пользователь №: 42 874



Добрый день

Проблема соединения 3G модема Telit к RL-TCPNet на STM32F4 используя PPP соединение.

Начал с того, что проверил RL-TCPNet стек PPP соединение подключившись к нему с компьютера, как указано в демо для данного Keil стека. Микроконтроллер ждет соединение после команды "ppp_listen ( "Keil","");". Компьютер первым начинает передавать данные (LCP, NCP and e.t.c.), все работает отлично.

Теперь пытаюсь подключить UL-865 (Telit, 3G) к STM32F4 для выхода в интернет. После команды модему "ATD*99***1#" он отвечает "CONNECT" и начинает первым передавать пакеты для соединения. STM32F4 находиться в ждущем режиме команда "ppp_listen ( "Keil","");SendToPPPStack ("CLIENT");". Модем видно отсылает одинаковые пакеты, около 10-ти и затем разъединяет связь "NO CARRIER". Стек не отвечает на данные запросы и связь не устанавливается. Мне кажеться, что Keil стек не разработан для работы с модемами и готов только подключаться к компьютеру или неправильные настройки PPP. Кто сталкивался с данной проблемой?
Кто может подсказать, по данному вопросу?

Я раньше пробывал подключить STM32F4 к USB модему E220, данное подключение работает т.к. модем находится в ожидании пакетов PPP после команды "ATD*99***1#". Стек в режиме "client" ( использую команды ppp_connect ("","", "");SendToPPPStack ("CLIENTSERVER");" Созданная тема здесь.
Такую же схему использовал для подключения к модему GL-865 ( Telit). В таком модеме есть возможность настроить его как PPP Server и он ожидает подключения. То же все работает.

Go to the top of the page
 
+Quote Post
Sergiy26
сообщение Jan 2 2015, 11:00
Сообщение #2


Участник
*

Группа: Участник
Сообщений: 28
Регистрация: 1-01-09
Пользователь №: 42 874



Всем огромное спасибо за помощь....

Теперь ближе к делу.
Сначала совет: советую подключить компьютер к модему через COM соединение. Win XP имеет достаточно инструментов для этого. Первое, что станет ясно, так это правильно ли указан APN ( Access Point Name). Работает ли модем с данным оператором и т.д.

Теперь непосредственно к RL-TCPNet from Keil:
1. Демо которое предлогают вместе со стеком это хорошо, но увеличить буфер приема и передачи по USART рекомендую с 256 до 1600. Насколько я помню, максимум размер полного TCP пакета 1514 ( Ethernet Frame Max Transfer Unit from Net_Config.h). Я предлогаю этот Frame покрыть, иначе кто его знает сколько инфы вы передаете.
2. Разделить буфер когда модем инициируеться и непосредственно общается по РРР. RL-TCPNet не очень любит видеть у себя в буфере "ATD*99***1#" и другие команды, а так же "CONNECT" в ответ. Заполняйте буфер для стека информацией от модема после подсоединения к 3G сети ( ответ от модема "CONNECT" ).
3. Будьте аккуратны с IRQ по USART, особенно если работаете под RTOS. Еще раз, когда Keil дает демо это здорово, и далее по тексту...
4. Даже если модем начинает связь первым ( отсылает LCP пакеты ), Я использовал команду ppp_connect ( "","","" );os_dly_wait ( 500 );SendToPPPStack ("CLIENTSERVER");

Это мои личные заметки.

Проблема решена.

Go to the top of the page
 
+Quote Post
kan35
сообщение Jan 3 2015, 08:17
Сообщение #3


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Я заметил, что beeline и megafon работают отлично даже с неправильными настройками APN, мтс не проверял. Хотя важно внести корректные конечно.
1. 1514 - это размер ethernet пакета, но у вас нет ethernet, кроме того, в процессе LCP модем стек договаривается с сервером какие у обоих возможности по буферам, по возможностям сборки дефрагментированных пакетов и т д, неправильные настройки могут только привести к пониженной производительности. Если протокол не может самонстроиться - стоит обратить внимание на другие стеки.
2. логично, хотя полагаю, это не может завалить стек
3. Да, будьте аккуратны:-)
4. Тут не могу ничего сказать, в свое время я использовал lwIP с модемом и там все очень просто было. Был в конфигурации с FreeRTOS, при которой создавалось 2 потока: PPP и TCP, и для использования стека требовалось сделать только 2 кастомных функции - передачу и прием байтов в UART (в PPP мессадж бокс), никаких буферов не надо было создавать вне стека, стек сам делал все необходимое.

Вообще ваше описание проблемы не ясное. Понятие сервера и клиента размыто. Сервер - это тот компьютер, который стоит где то у оператора. Клиент - в данном случае ваша микроконтроллерная система. Модем - лишь модем, он не сервер и не клиент... Стек наверное, может выполнять роль сервера, но у вас должен быть "клиент" однозначно.

Сообщение отредактировал kan35 - Jan 3 2015, 08:19
Go to the top of the page
 
+Quote Post
Sergiy26
сообщение Jan 3 2015, 11:23
Сообщение #4


Участник
*

Группа: Участник
Сообщений: 28
Регистрация: 1-01-09
Пользователь №: 42 874



У меня такое ощущение, что Я прохожу kan35 у вас экзамен. Ваша помощь требовалась 25 декабря, когда создавался топик. Я написал для тех у кого есть вопросы и нет ответов.

kan35, где в Demo from Keil указан размер принимаемого и передающего буферов, которые TCP stack использует для "договаривается с сервером "?

Когда пишешь вопрос, то иногда отвечают, что вопрос или тех. задание не совсем ясно. Я пишу про размер буфера RL-TCPNet PPP стека. В ответе: "я использовал lwIP с модемом и там все очень просто было". Разные люди - разное восприятие. Проехали...

Админ, если возможно, то отпишите в имени топика [РЕШЕНО], может кому поможет.
Go to the top of the page
 
+Quote Post
kan35
сообщение Jan 3 2015, 15:40
Сообщение #5


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



для конфигурации размера пакета нужно подкручивать TCP_MAX_SEG_SIZE, соответственно из этого числа формируется размер пакета PPP, и в момент работы LCP negotiation сервер и клиент сообщают друг другу какой размер пакета у того и другого и принимают для работы наименьший. Потому, ошибиться в размере невозможно, спасибо википедии))).
Вы задали вопрос, потом отвечаете на него якобы, но я вижу, что пункты 1-4 из вашего решения не соответствуют или слабо коррелируют с поставленной вами же проблемой. А раз вы пишите, что проблема решена, но интересно было бы понять в чем именно было дело, пока вы сами не знаете в чем, и как это поможет кому то еще - не понятно. Мне самому интересно, так как в свое время повозился с другим стеком. Не обижайтесь.
Go to the top of the page
 
+Quote Post
Sergiy26
сообщение Jan 3 2015, 21:10
Сообщение #6


Участник
*

Группа: Участник
Сообщений: 28
Регистрация: 1-01-09
Пользователь №: 42 874



Цитата(kan35 @ Jan 3 2015, 19:40) *
для конфигурации размера пакета нужно подкручивать TCP_MAX_SEG_SIZE, соответственно из этого числа формируется размер пакета PPP, и в момент работы LCP negotiation сервер и клиент сообщают друг другу какой размер пакета у того и другого и принимают для работы наименьший. Потому, ошибиться в размере невозможно, спасибо википедии))).
Вы задали вопрос, потом отвечаете на него якобы, но я вижу, что пункты 1-4 из вашего решения не соответствуют или слабо коррелируют с поставленной вами же проблемой. А раз вы пишите, что проблема решена, но интересно было бы понять в чем именно было дело, пока вы сами не знаете в чем, и как это поможет кому то еще - не понятно. Мне самому интересно, так как в свое время повозился с другим стеком. Не обижайтесь.



Значиться так, в RL-TCPNet параметра TCP_MAX_SEG_SIZE я не нашел. Укажите файл где этот параметр храниться! Я нашел #define TCP_MAXSEGSZ 1460 из файла Net_Config.c. А теперь берем демо файл "Serial_STM32x.с" в котором объявляеться буфер
Код
/* Local variables */
struct buf_st  {
  U8 in;
  U8 out;
  U8 buf [256];
};
А теперь вопрос. Где тут: "стек договаривается с сервером какие у обоих возможности по буферам, по возможностям сборки дефрагментированных пакетов"? Если вы не поняли о чем речь с начала, то поверю. Это то, что я имел ввиду.

Теперь открываем страницу с ткаимим словами: The Windows client sends the string "CLIENT". The Keil evaluation board must then send the string "CLIENTSERVER". When operating as a server, the Keil evaluation board must send the string "CLIENT". The Windows client must respond with the string "CLIENTSERVER". Я надеюсь вам теперь ясно, что имелось в виду под именами: Server/Client?

В первом сообщении Я изложил проблему с вопросом. Затем нашел в чем я ошибся и по пунктам написал решение для тех, кто имеет проблему как я: подключения TCP stack к модему по протоколу PPP.


Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd July 2025 - 21:31
Рейтинг@Mail.ru


Страница сгенерированна за 0.01391 секунд с 7
ELECTRONIX ©2004-2016