Самоделкин 0 17 марта, 2021 Опубликовано 17 марта, 2021 · Жалоба Чудес похоже нет. Я уже писал - оператор "пробрасывает" порты. Вот и получается первый пакет "пропадает" в неизвестном IP/ Повторно уже уходит на нужный который реальный. Все будет работать на время аренды IP/ Сеть оператора , он там работает как ему удобно. Такой режим работы "добрая" воля оператора которую он может изменить в любой момент. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vit496 0 18 марта, 2021 Опубликовано 18 марта, 2021 · Жалоба 14 hours ago, rudy_b said: На все последующие send - модем нормально получает все ответы, Странно все это. Вроде как команда AT+CIPSTART="UDP"... по факту ничего не делает, никакого соединения не устанавливает, модем всегда сразу отвечает CONNECT OK, так как в UDP нет соединений и сессий. А с сим-картой другого оператора вы пробовали? Если так на всех операторах, то что-то с программой вашей не так или с модемом. На SIM800C UDP (и NTP через UDP) работает исправно на всех операторах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 18 марта, 2021 Опубликовано 18 марта, 2021 · Жалоба 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 12 18 марта, 2021 Опубликовано 18 марта, 2021 · Жалоба SIM800L непредсказуемая лошадка. Он не предназначается для Европейского рынка и что там с прошивками сам черт ногу сломит. Поэтому его работа вполне может отличаться от SIM800C или европейского братца SIM800H. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 18 марта, 2021 Опубликовано 18 марта, 2021 · Жалоба Проверил. В одной UDP сессии и первый и все последующие пакеты приходят на сервер с одного и того же адреса и порта. Заодно проверил NTP через UDP. В одной UDP сессии делаю 4 запроса. Первый - не выполняется, на остальные три ответ нормальный. Т.е. пропадание первого ответа в UDP сессии подтверждается и тут. P.S. Заодно проверил и NTP через соответствующую функцию модема - та же история, первый запрос пропадает следующий проходит нормально. Вот такие пироги... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 18 марта, 2021 Опубликовано 18 марта, 2021 · Жалоба Теперь все то же самое надо проверить с другим модемом - этот 800L и в самом деле может быть глючным. UDP, по крайней мере, заработал - ожидаемо никакой мистики. Так почему же исходно вообще ничего не работало ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 18 марта, 2021 Опубликовано 18 марта, 2021 · Жалоба 1 hour ago, rx3apf said: Так почему же исходно вообще ничего не работало ? А потому, что я делал только одну попытку связи с сервером NTP в одной UDP сессии. Ессно ответного пакета я не получал. А потом я перезагружал UDP сессию и делал следующую попытку. С тем же результатом. Вместо того, чтобы сделать несколько попыток в одной сессии. А при использовании NTP команд модема, я (фиг знает почему) делал несколько попыток в одной сессии - и все работало со второй попытки. А догадаться, что только первый ответный пакет пропадает - мозгов не хватило. И еще - в режимах чистого UDP я использовал чужой сервер SocketTest 3.0.0. Причем проверил его в режиме TCP - отлично работает в обе стороны. А вот в режиме UDP - оказалось глючит. Сервер слушал заданный порт, входящие пакеты получал и показывал адрес и порт отправителя - все честно. Отправка ответных пакетов делалась ручками (задание адреса и порта из входного пакета). Но вот модем этих ответных пакетов не получал и сейчас не получает, ни первого, ни следующих. Что-то в этом сервере не то, но продукт чужой, фиг его знает в чем дело. А когда написал свой UDP сервер - сразу начал получать ответные пакеты кроме первого и стало все понятно. Другого модема сейчас нет. Но скоро буду делать нормальный модем на SIM800C, вот тогда и посмотрю что там будет. Пока точно неизвестно кто глючит - модем или оператор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба Разобрался с SocketTest 3.0.0. Внимательно посмотрел ответные пакеты Wireshark. Раньше смотрел только адреса и порты, а сейчас влез в заголовок ответного пакета. В нем обнаружилось несовпадение контрольной суммы заголовка: Header checksum: 0x0000 [incorrect, should be 0x3589 (maybe caused by "IP checksum offload"?)] Вероятно поэтому ответные пакеты и не доходят до модема. Не пользуйтесь этой программой. Заодно еще раз внимательно посмотрел пинг средствами модема. Картина та же - первый запрос - всегда таймаут, три последующих проходят нормально. Ну, вроде теперь все понятно, кроме того кто виноват -модем или оператор. Спасибо всем ответившим. Когда доберусь до SIM800C отпишусь, правда это будет не скоро. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба 11 минут назад, rudy_b сказал: Вероятно поэтому ответные пакеты и не доходят до модема. Не пользуйтесь этой программой. Вроде как поле контрольной суммы в IPv4 не обязательно ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба 1 час назад, rx3apf сказал: Вроде как поле контрольной суммы в IPv4 не обязательно ? Вроде, в настройках сетевой карты можно установить подсчет контрольной суммы IPv4 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба Главное, что ее можно не считать и 0000 в этом поле допустимый вариант, о этом не надо беспокоиться. Если проблема и есть - она явно в другом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба Что-то не похоже. Почему тогда мой UDP сервер, запущенный в тех же условиях вместо SocketTest не делает этой ошибки? И ответные пакеты от него (исключая первый) всегда доходят? А пакеты SocketTest не доходят никогда? Причем и адрес и порт те же. Т.е. совершенно очевидна ошибка именно в пакете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба Ух, тяжек путь познания. Запустил Wireshark и посмотрел ответные пакеты от моего UDP сервера и от SocketTest в одной сессии модема. Вы правы, контрольная сумма IP заголовка может быть равна нулю - и так и есть в обоих случаях. Пакеты различаются только в одной детали - порте отправителя. Мой сервер отвечает с того же порта, на который пришел пакет. А вот SocketTest отвечает с другого порта, то ли случайно выбранного, то ли назначенного, но изменить его ручками нельзя. Формально это вполне допустимо, но, похоже, не в этом случае. Получается, что оператор или сам модем блокируют пакеты, если порт отправителя не совпадает с тем портом, который был указан при коннекте. Можно предположить, для чего была сделана такая фильтрация. В старых форумах народ ругался на то, что как только открываешь UDP, на него начинает валиться разный мусор, предложения от операторов и т.п. Эти пакеты попадают в трафик и платит за них пользователь. Возможно оператор добавил такую фильтрацию для блокировки этого. А может это делает сам модем. Так что моя ругань на SocketTest неправильна, точнее не совсем правильна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 133 19 марта, 2021 Опубликовано 19 марта, 2021 · Жалоба Ваш модем сидит за NATом оператора. Откуда этому NATу знать, на какой из тысяч SIM800 ему переправлять пакет, пришедший из интернета? Если на этот адрес-порт недавно уходил пакет из внутренней сети от вашего модема - он запомнил отправителя и отправит пакет вашему модему. А если нет - не будет же он транслировать этот пакет всем модемам сети. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 20 марта, 2021 Опубликовано 20 марта, 2021 · Жалоба В момент подъема GPRS модему присваивается локальный адрес, который сохраняется до отключения GPRS. В момент коннекта (запуска сессии UDP модема), формируются и сохраняются данные NAT, т.е. выделяются внешний адрес и порт и запоминается связь между внешним адресом и портом и локальным адресом и портом. Все пакеты, поступающие на выделенные внешний адрес и порт транслируются на соответствующий локальный адрес и порт. Вот на какой именно локальный порт - не знаю, задание порта UDP не влияет или незаметно. Запомненные параметры NAT должны сохранятся до дисконнекта (завершения сессии UDP модема). Так что у оператора нет проблем на какой локальный адрес отправить пакет, пришедший на конкретный внешний адрес и порт. Эта информация запомнена в NAT и сохраняется вплоть до дисконнекта. Другие данные поступающего пакета ( в частности порт отправителя) в общем случае не должны проверятся. То, что пакеты фильтруются по порту отправителя - это дополнительная фича. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться