[Самоделкин 0]

Чудес похоже нет. Я уже писал - оператор "пробрасывает" порты.

Вот  и получается первый пакет "пропадает" в неизвестном IP/

Повторно уже уходит на нужный который реальный. Все будет работать на время аренды IP/

 Сеть оператора , он там работает как ему удобно. Такой режим работы "добрая" воля оператора которую он может изменить в любой момент. 

[vit496 0]

14 hours ago, rudy_b said:

На все последующие send - модем нормально получает все ответы,

Странно все это. Вроде как команда AT+CIPSTART="UDP"... по факту ничего не делает, никакого соединения не устанавливает, модем всегда сразу отвечает CONNECT OK, так как в UDP нет соединений и сессий. А с сим-картой другого оператора вы пробовали? Если так на всех операторах, то что-то с программой вашей не так или с модемом. На SIM800C UDP (и NTP через UDP) работает исправно на всех операторах.

[rudy_b 1]

13 hours ago, Самоделкин said:

Я уже писал - оператор "пробрасывает" порты.

Возможно. Но, он иногда перебрасывает меня на другой "фиг его знает что" и при этом модем дает отдельное сообщение. Здесь его нет.

Кроме того, после получения локального IP при подъеме GPRS он не имеет права это делать. Я смотрел - локальный адрес и порт модема я специально не выставляю, они равны нулю. Кстати надо бы попробовать снова задать UDP порт и посмотреть что будет. Я раньше его задавал, но, потом, в экспериментах, перестал.

И после коннекта все пакеты к серверу идут с одного и того же адреса и порта (и первый и остальные), т.е. адрес и порт стабильны. Но это навскидку, специально не отслеживал, проверю.

 

2 hours ago, vit496 said:

Вроде как команда AT+CIPSTART="UDP"... по факту ничего не делает, никакого соединения не устанавливает

В этот момент, точнее при коннекте, должны задаваться и запоминаться параметры прокси (NAT). И они должны быть строго постоянны до дисконнекта.

 

2 hours ago, vit496 said:

А с сим-картой другого оператора вы пробовали?

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

 

2 hours ago, vit496 said:

На SIM800C UDP (и NTP через UDP) работает исправно на всех операторах.

У меня SIM800L. Да и работает все исправно с точностью до первого ответа.

[CADiLO 9]

SIM800L непредсказуемая лошадка.

Он не предназначается для Европейского рынка и что там с прошивками сам черт ногу сломит.

Поэтому его работа вполне может отличаться от SIM800C или европейского братца SIM800H.

 

[rudy_b 1]

Проверил. В одной UDP сессии и первый и все последующие пакеты приходят на сервер с одного и того же адреса и порта.

Заодно проверил NTP через UDP. В одной UDP сессии делаю 4 запроса. Первый - не выполняется, на остальные три ответ нормальный.

Т.е. пропадание первого ответа в UDP сессии подтверждается и тут.

 

P.S. Заодно проверил и NTP через соответствующую функцию модема - та же история, первый запрос пропадает следующий проходит нормально.

 

Вот такие пироги...

[rx3apf 0]

Теперь все то же самое надо проверить с другим модемом - этот 800L и в самом деле может быть глючным. UDP, по крайней мере, заработал - ожидаемо никакой мистики. Так почему же исходно вообще ничего не работало ?

[rudy_b 1]

1 hour ago, rx3apf said:

Так почему же исходно вообще ничего не работало ?

А потому, что я делал только одну попытку связи с сервером NTP в одной UDP сессии. Ессно ответного пакета я не получал. А потом я перезагружал UDP сессию и делал следующую попытку. С тем же результатом. Вместо того, чтобы сделать несколько попыток в одной сессии.

А при использовании NTP команд модема, я (фиг знает почему) делал несколько попыток в одной сессии - и все работало со второй попытки. А догадаться, что только первый ответный пакет пропадает - мозгов не хватило.

 

И еще - в режимах чистого UDP я использовал чужой сервер SocketTest 3.0.0. Причем проверил его в режиме TCP - отлично работает в обе стороны. А вот в режиме UDP - оказалось глючит.  Сервер слушал заданный порт, входящие пакеты получал и показывал адрес и порт отправителя - все честно. Отправка ответных пакетов делалась ручками (задание адреса и порта из входного пакета). Но вот модем этих ответных пакетов не получал и сейчас не получает, ни первого, ни следующих. Что-то в этом сервере не то, но продукт чужой, фиг его знает в чем дело. А когда написал свой UDP сервер - сразу начал получать ответные пакеты кроме первого и стало все понятно.

 

Другого модема сейчас нет. Но скоро буду делать нормальный модем на SIM800C, вот тогда и посмотрю что там будет. Пока точно неизвестно кто глючит - модем или оператор.

[rudy_b 1]

Разобрался с SocketTest 3.0.0. Внимательно посмотрел ответные пакеты Wireshark. Раньше смотрел только адреса и порты, а сейчас влез в заголовок ответного пакета. В нем обнаружилось несовпадение контрольной суммы заголовка:

Header checksum: 0x0000 [incorrect, should be 0x3589 (maybe caused by "IP checksum offload"?)]

Вероятно поэтому ответные пакеты и не доходят до модема. Не пользуйтесь этой программой.

 

Заодно еще раз внимательно посмотрел пинг средствами модема. Картина та же - первый запрос - всегда таймаут, три последующих проходят нормально.

 

Ну, вроде теперь все понятно, кроме того кто виноват -модем или оператор.

 

Спасибо всем ответившим.

 

Когда доберусь до SIM800C отпишусь, правда это будет не скоро.

 

 

[rx3apf 0]

11 минут назад, rudy_b сказал:

Вероятно поэтому ответные пакеты и не доходят до модема. Не пользуйтесь этой программой.

Вроде как поле контрольной суммы в IPv4 не обязательно ?

[adnega 10]

1 час назад, rx3apf сказал:

Вроде как поле контрольной суммы в IPv4 не обязательно ?

Вроде, в настройках сетевой карты можно установить подсчет контрольной суммы IPv4

[rx3apf 0]

Главное, что ее можно не считать и 0000 в этом поле допустимый вариант, о этом не надо беспокоиться. Если проблема и есть - она явно в другом.

[rudy_b 1]

Что-то не похоже.

Почему тогда мой UDP сервер, запущенный в тех же условиях вместо SocketTest не делает этой ошибки?

И ответные пакеты от него (исключая первый) всегда доходят?

А пакеты SocketTest не доходят никогда? Причем и адрес и порт те же.

 

Т.е. совершенно очевидна ошибка именно в пакете. 

[rudy_b 1]

Ух, тяжек путь познания.

Запустил Wireshark и посмотрел ответные пакеты от моего UDP сервера и от SocketTest в одной сессии модема.

Вы правы, контрольная сумма IP заголовка может быть равна нулю - и так и есть в обоих случаях.

Пакеты различаются только в одной детали - порте отправителя.

 

Мой сервер отвечает с того же порта, на который пришел пакет.

 

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

 

Получается, что оператор или сам модем блокируют пакеты, если порт отправителя не совпадает с тем портом, который был указан при коннекте.

 

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

Возможно оператор добавил такую фильтрацию для блокировки этого. А может это делает сам модем.

 

Так что моя ругань на  SocketTest неправильна, точнее не совсем правильна.

[Сергей Борщ 119]

Ваш модем сидит за NATом оператора. Откуда этому NATу знать, на какой из тысяч SIM800 ему переправлять пакет, пришедший из интернета? Если на этот адрес-порт недавно уходил пакет из внутренней сети от вашего модема - он запомнил отправителя и отправит пакет вашему модему. А если нет - не будет же он транслировать этот пакет всем модемам сети.

[rudy_b 1]

В момент подъема GPRS модему присваивается локальный адрес, который сохраняется до отключения GPRS.

В момент коннекта (запуска сессии UDP модема), формируются и сохраняются данные NAT, т.е. выделяются внешний адрес и порт и запоминается связь между внешним адресом и портом и локальным адресом и портом. Все пакеты, поступающие на выделенные внешний адрес и порт транслируются на соответствующий локальный адрес и порт. Вот на какой именно локальный порт - не знаю, задание порта UDP не влияет или незаметно.

Запомненные параметры NAT должны сохранятся до дисконнекта (завершения сессии UDP модема). Так что у оператора нет проблем на какой локальный адрес отправить пакет, пришедший на конкретный внешний адрес и порт. Эта информация запомнена в NAT и сохраняется вплоть до дисконнекта.

Другие данные поступающего пакета ( в частности порт отправителя) в общем случае не должны проверятся. То, что пакеты фильтруются по порту отправителя - это дополнительная фича.