xmega 0 12 ноября, 2012 Опубликовано 12 ноября, 2012 · Жалоба А есть возможность посмотреть сетевой обмен на сервере? Если под win32, используйте сетевой анализатор типа SoftPerfect Network Protocol Analyzer или что-то в этом роде, запустив его на машине сервера. Интересно, отрабатывается ли вообще тройное рукопожатие при tcp-конекте модуля к серверу, или это модулю только кажется. И приходит ли затем на сетевой интерфейс IP-пакет с данными "1234567890". Если нет возможности проверить, напишите в личку: подключитесь на мой ip, я гляну. модуль поднимаю ручками, сам модуль стоит на макетке, подключил только COM порт. С сервером соединение открывает с ошибкой, т.е. сервер не открыл соединение а вот модем открыл и вывел "CONNECT OK". После этого данные не поступают на сервер что и понятно т.к. соединение не получилось установить. Вопрос, почему в 95...98% случаев у модема не получается установить соединение с сервером, хотя он выдает "CONNECT OK" и уровень сигнала соты приличный, "+CSQ: 31,0". В случае когда соединение проходит успешно, модем данные отправляет нормально, вот только это продолжается не долго, минут через 5...10 опять не может отправлять, запрос "AT+QISTAT" ответ "STATE: CONNECT OK", сигнал тоже "+CSQ: 31,0", а вот сервер просто перестает получать пакеты из соединения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gegel 0 12 ноября, 2012 Опубликовано 12 ноября, 2012 (изменено) · Жалоба Опять же, чем гадать о происходящем, запустите на стороне сервера сетевой снифер и помотрите, что там на самом деле происходит: откуда приходит fin-пакет, и приходит ли он вообще. Возможно, просто NAT сисопа в таймаут уходит ( у вас ведь серый айпи 10.х.х.х), тогда надо keepalive вводить. Вобщем, одним созерцанием терминалки модема тут не поможешь, нужен более конструктивный подход с пониманием того, как функционирует tcp-соединение на уровне ip-пакетов, а не того, как его открыть/закрыть. Изменено 12 ноября, 2012 пользователем GeGeL Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmega 0 13 ноября, 2012 Опубликовано 13 ноября, 2012 (изменено) · Жалоба Опять же, чем гадать о происходящем, запустите на стороне сервера сетевой снифер и помотрите, что там на самом деле происходит: откуда приходит fin-пакет, и приходит ли он вообще. Возможно, просто NAT сисопа в таймаут уходит ( у вас ведь серый айпи 10.х.х.х), тогда надо keepalive вводить. Вобщем, одним созерцанием терминалки модема тут не поможешь, нужен более конструктивный подход с пониманием того, как функционирует tcp-соединение на уровне ip-пакетов, а не того, как его открыть/закрыть. ЗАПУСКАЛ снифер! сказал уже о результате. тройное рукопожатие не завершается, получаю только первый запрос от модема, все остальные ответы сервера модем не видит и не отвечает на них. Хотя строчку CONNECT OK выдает очень резво. вот что показывает: http://imglink.ru/show-image.php?id=424aef...78e52846cd2e228 http://imglink.ru/show-image.php?id=bd0fb9...812d45f706551db http://imglink.ru/show-image.php?id=7b27d0...790103276383dc9 http://imglink.ru/show-image.php?id=a9fc1f...6866813fa37d79b Процесс начала сеанса TCP - обозначаемое как "рукопожатие" (handshake), состоит из 3 шагов. 1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. * Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента. o В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED. o В случае неудачи сервер посылает клиенту сегмент с флагом RST. 2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK. * Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED. * Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться. * Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново. 3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED. * В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED. Что мне то делать, если модем неправильно выполняет требуемую процедуру подключения и рапортует CONNECT OK? Опять же повторюсь такое происходит только на карточках "Мегафон", остальные операторы работают нормально, если ставить карточку "Мегафон" в SIM900 то работает нормально. Изменено 13 ноября, 2012 пользователем xmega Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 13 ноября, 2012 Опубликовано 13 ноября, 2012 · Жалоба Попробуйте в другой аналогичный модуль карточку воткнуть. То есть тут же на столе замените имеющийся модуль на аналогичный и попробуйте коннект. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmega 0 13 ноября, 2012 Опубликовано 13 ноября, 2012 · Жалоба Попробуйте в другой аналогичный модуль карточку воткнуть. То есть тут же на столе замените имеющийся модуль на аналогичный и попробуйте коннект. Конечно пробовал, ситуация не меняется. Нашли это, потому что все оборудование перестало работать на мегафоне, вот и разбираюсь. Клиенту чуть ли не за свои деньги карточки покупаем других операторов, договариваемся там, говорим мегафон оцтой... купите МТС! Или любой другой но не мегафон! На что получаем резонный ответ: "А может дело не в мегафоне?... ", "А где гарантии что мы сейчас заменим все симки, через неделю вы опять не попросите симки менять?...", "Кто этот банкет оплачивать будет?..." Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gegel 0 13 ноября, 2012 Опубликовано 13 ноября, 2012 (изменено) · Жалоба Да, ситуация действительно весьма интересная. Можно было бы все списать на NAT сисопа, если бы не одно но: Вы в начале утверждали, что на сим900 в полностью аналогичной ситуации все работает. Можно глянуть снифером ситуацию с сим900? Интересен исходящий порт со стороны NAT провайдера. Попробуйте также на другом порту сервер поднять. Если с портами все так же, то, похоже, что-то тонкое в стеке модема... Для интереса можно также попробовать проверить UDP-обмен: поднять эхо-UDP сервер и со стороны модема посылать UDP-пакеты и смотреть ответ. Интересно, он вообще в данной ситуации хоть что-то принимает?... И еще один эксперимент неплохо бы: поднять мегафонное соединение с РС, подключив М12 по RS232-PPP в качестве стандартного модема и открывая соединение с сервером с PC. Т.о. дифференцируем проблемы провайдера от проблем стека. ПС: и еще вопрос - если сервер вообще отключен, выдается ли CONNECT OK? Изменено 13 ноября, 2012 пользователем GeGeL Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CADiLO 12 13 ноября, 2012 Опубликовано 13 ноября, 2012 · Жалоба Может я ошибаюсь - тогда пусть меня питерские коллеги поправят - в свое время с одним из операторов России были проблемы и с SIM900 и даже карточки для устранения на симком высылали. Но был ли это Мегафон 100% не скажу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmega 0 14 ноября, 2012 Опубликовано 14 ноября, 2012 (изменено) · Жалоба Да, ситуация действительно весьма интересная. Можно было бы все списать на NAT сисопа, если бы не одно но: Вы в начале утверждали, что на сим900 в полностью аналогичной ситуации все работает. Можно глянуть снифером ситуацию с сим900? Интересен исходящий порт со стороны NAT провайдера. Попробуйте также на другом порту сервер поднять. Если с портами все так же, то, похоже, что-то тонкое в стеке модема... Для интереса можно также попробовать проверить UDP-обмен: поднять эхо-UDP сервер и со стороны модема посылать UDP-пакеты и смотреть ответ. Интересно, он вообще в данной ситуации хоть что-то принимает?... И еще один эксперимент неплохо бы: поднять мегафонное соединение с РС, подключив М12 по RS232-PPP в качестве стандартного модема и открывая соединение с сервером с PC. Т.о. дифференцируем проблемы провайдера от проблем стека. ПС: и еще вопрос - если сервер вообще отключен, выдается ли CONNECT OK? Значит вот какая ситуация, то о чем вы говорите тоже пробовал. Если сервер не запущен то и CONNECT OK не выдает в том то и прикол, что подключение начинается но разрушается на передаче ACK на SYN модема. Винда при этом не может создать связанного сокета а вот модем МОЖЕТ! CONNECT OK. Если сервер вообще не запускать то все как и должно быть CONNECT FAIL, т.е. выходит, что кто то вместо моего сервера все это дело подтверждает ну или стек такой у модема кривенький. Подключать M10 по RS232-PPP в качестве стандартного модема не очень хочется время тратить, потому как переделываю протокол приборов на UDP и делаю свой протокол доставки. Ну и собственно UDP я пробовал и работает нормально. По поводу SIM900 там все в порядке с "рукопожатием" при подключении причем подключается он явно дольше! т.е. CONNECT OK выдает когда уже я вижу снифером, что винда сокет образовала. Модем M10 выдает CONNECT OK при первом же ответном пакете сервера при установлении соединения т.е. я вижу, что соединение ещё в стадии открытия а он уже отвечает CONNECT OK. ...Да, ситуация действительно весьма интересная... да ОЧЕНЬ Люлей мне уже выдали за такое, а интересно в Quectel серьезно занимаются такими случаями? просто вот любопытно как там разбор полетов происходит? Изменено 14 ноября, 2012 пользователем xmega Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gegel 0 14 ноября, 2012 Опубликовано 14 ноября, 2012 · Жалоба Значит вот какая ситуация, то о чем вы говорите тоже пробовал. Если сервер не запущен то и CONNECT OK не выдает в том то и прикол, что подключение начинается но разрушается на передаче ACK на SYN модема. Винда при этом не может создать связанного сокета а вот модем МОЖЕТ! CONNECT OK. Если сервер вообще не запускать то все как и должно быть CONNECT FAIL, т.е. выходит, что кто то вместо моего сервера все это дело подтверждает ну или стек такой у модема кривенький. Нет, не так немного, как Вы описали. Вот что происходит, я так понимаю: 1. Модем посылает первичный SYN, он удачно доходит на сервер. 2. Сервер инициирует сокет и посылает модему свой SYN. 3. Этот пакет модем ПОЛУЧАЕТ (иначе не выдал бы CONNECT OK), скорее всего отсылает серверу ACK и вполне резонно считает, что соединение создано. 4. Но вот этот ACK на сервер не доходит. Но почему? Банально пакетлосс? (тем более что иногда, с ваших слов, все же соединение устанавливается). Возможно, сокет стека М12, в отличие от SIM900, делает меньшее к-во повторов (или не делает совсем). Если так, то надо бы переориентировать модем не на CONNECT OK, а на подтверждение получения любых инит-данных, иначе рвать соединение и устанавливать по новому до успеха. Но, что интересно, в результате каждой попытки имеем зависший в SYN-RECEIVED сокет на сервере, который ликвидируется по таймауту. При агрессивных реконектах множества устройств - типичная DDos получится. По поводу своего протокола на базе UDP - поддерживаю всеми конечностями :) Для M2M это однозначно лучший выбор, просто народ ленится креативиться. Тут вы сможете заточить таймауты, подтверждения и т.п. под свою задачу, что сделает обмен еффективнее и надежнее. Для примера Hamachi именно UDP как несущий использует. А по поводу Quectel - то писать надо непосредственно на их сайте саппорту, подробно описав проблему. Обычно они оперативно переадресовывают разработчику данного модуля кода. Но перед этим стоит проверить на других прошивках: баг явный, по идее могли уже давно исправить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmega 0 15 ноября, 2012 Опубликовано 15 ноября, 2012 · Жалоба Нет, не так немного, как Вы описали. Вот что происходит, я так понимаю: 1. Модем посылает первичный SYN, он удачно доходит на сервер. 2. Сервер инициирует сокет и посылает модему свой SYN. 3. Этот пакет модем ПОЛУЧАЕТ (иначе не выдал бы CONNECT OK), скорее всего отсылает серверу ACK и вполне резонно считает, что соединение создано. 4. Но вот этот ACK на сервер не доходит. Но почему? Банально пакетлосс? (тем более что иногда, с ваших слов, все же соединение устанавливается). Возможно, сокет стека М12, в отличие от SIM900, делает меньшее к-во повторов (или не делает совсем). Если так, то надо бы переориентировать модем не на CONNECT OK, а на подтверждение получения любых инит-данных, иначе рвать соединение и устанавливать по новому до успеха. Но, что интересно, в результате каждой попытки имеем зависший в SYN-RECEIVED сокет на сервере, который ликвидируется по таймауту. При агрессивных реконектах множества устройств - типичная DDos получится. По поводу своего протокола на базе UDP - поддерживаю всеми конечностями :) Для M2M это однозначно лучший выбор, просто народ ленится креативиться. Тут вы сможете заточить таймауты, подтверждения и т.п. под свою задачу, что сделает обмен еффективнее и надежнее. Для примера Hamachi именно UDP как несущий использует. А по поводу Quectel - то писать надо непосредственно на их сайте саппорту, подробно описав проблему. Обычно они оперативно переадресовывают разработчику данного модуля кода. Но перед этим стоит проверить на других прошивках: баг явный, по идее могли уже давно исправить. да так и есть, сокет сервера не доходит до состояния ESTABLISHED. Хотя иногда доходит и обмен вроде возможен, но работает 10 мин. и потом опять затык. :( Теперь вопрос: почему это происходит только на одном операторе Мегафон? Всю ситуацию так же изложил тех. поддержки Quectel, сказали занимаемся, проверяем... Может в другом дело? я не знаю... наводки... помехи... уже голову всю сломал :( хотя уровень сигнала показывает больше не куда, симка стоит надежно (хотя могу и запаять намертво, но это уже перегиб), антенну проверял, разъемы менял, разные модемы со склада брал, короче ахтунг кажись UDP, это все на что стоит рассчитывать. Не очень понимаю для чего производители модемов анонсируют все эти новые технологии типа 3G... и все такое, тут самые простецкие вещи не работают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 15 ноября, 2012 Опубликовано 15 ноября, 2012 · Жалоба По поводу своего протокола на базе UDP - поддерживаю всеми конечностями :) Для M2M это однозначно лучший выбор, просто народ ленится креативиться. Тут вы сможете заточить таймауты, подтверждения и т.п. под свою задачу, что сделает обмен еффективнее и надежнее. Для примера Hamachi именно UDP как несущий использует. Несколько не в тему, но я тоже немного не понимаю, зачем люди используют TCP для M2M. Все равно же идет, как правило, свой контроль пакетов. Единственный минус UDP - соединение в NAT опсоса живет от силы секунд 15. поэтому обратно данные надо пропихивать быстро. Ну и еще минус - в 285 приказе написано - устройство должно соединятся по TCP! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gegel 0 15 ноября, 2012 Опубликовано 15 ноября, 2012 · Жалоба Теперь вопрос: почему это происходит только на одном операторе Мегафон? Возможно, из-за потери IP-пакетов, причем скорее не по вине помех на радиосегменте, а, может, из-за каких-то шейперов в сети провайдера. Именно поэтому иногда соединяется. И именно поэтому спонтанно рвется соединение через случайное время. Как видно из сетевого лога, сервер повторяет свой SYN-пакет (так как не получает на него ACK), но, скорее всего, баг Quectel-сокета в том, что однажды получив SYN и ответив на него ACK, модем становится нечувствителен к повторным SYN, таким образом потерянный ACK не дублируется модемом. ПС: будьте готовы к масовым потерям и UDP-пакетов. Обязательно должен быть алгоритм многократной повторной отсылки по таймауту до подтверждения, а также периодически проверка связи (т.к. с пингом я уже обжегся, то троекратно отправляю UDP-DNS пакет на 8.8.8.8:53 - гораздо надежнее), переподключение GPRS при неудаче, и перезапуск модуля при таймауте времени, выделенного на поднятие GPRS (скажем, 3 мин). Если еще и внешний вотчдог на пике, то вобще неубиваемый девайс получается :) Единственный минус UDP - соединение в NAT опсоса живет от силы секунд 15. поэтому обратно данные надо пропихивать быстро. И в результате девайс может быть доступен из сервера (например, для управления) не в любой момент, а только после передачи очередного пакета данных. Если это неприемлемо, то надо вводить keepalive. Кстати открытая TCP по идее, живет в NAT столько же и тоже поддерживается с помощью keppalive (самим сокетом), так что трафик одинаково утекает. В случае с UDP даже экономнее за счет более коротких заголовков и того, что можно оптимально подобрать интервал под настройки конкретного NAT). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmega 0 16 ноября, 2012 Опубликовано 16 ноября, 2012 · Жалоба Возможно, из-за потери IP-пакетов, причем скорее не по вине помех на радиосегменте, а, может, из-за каких-то шейперов в сети провайдера. Именно поэтому иногда соединяется. И именно поэтому спонтанно рвется соединение через случайное время. Как видно из сетевого лога, сервер повторяет свой SYN-пакет (так как не получает на него ACK), но, скорее всего, баг Quectel-сокета в том, что однажды получив SYN и ответив на него ACK, модем становится нечувствителен к повторным SYN, таким образом потерянный ACK не дублируется модемом. ПС: будьте готовы к масовым потерям и UDP-пакетов. Обязательно должен быть алгоритм многократной повторной отсылки по таймауту до подтверждения, а также периодически проверка связи (т.к. с пингом я уже обжегся, то троекратно отправляю UDP-DNS пакет на 8.8.8.8:53 - гораздо надежнее), переподключение GPRS при неудаче, и перезапуск модуля при таймауте времени, выделенного на поднятие GPRS (скажем, 3 мин). Если еще и внешний вотчдог на пике, то вобще неубиваемый девайс получается :) И в результате девайс может быть доступен из сервера (например, для управления) не в любой момент, а только после передачи очередного пакета данных. Если это неприемлемо, то надо вводить keepalive. Кстати открытая TCP по идее, живет в NAT столько же и тоже поддерживается с помощью keppalive (самим сокетом), так что трафик одинаково утекает. В случае с UDP даже экономнее за счет более коротких заголовков и того, что можно оптимально подобрать интервал под настройки конкретного NAT). По UDP все хорошо и быстро передается, без всяких тормозов. Мне кажется что в TCP соединении и передаче, участвуют промежуточные узлы, которые берут на себя функции выдавать ACK. По верх TCP можно ещё протокол положить, многие же протоколы верхних уровней работают по TCP. Хотя я столкнулся с комплексной проблемой, во первых ладно бы просто по TCP пакеты теряться могут, бывает но редко. Но тут ещё и соединение не получается открывать нормально, точней никак не получается, 95 попыток из 100 неудачны. У меня прибор потратил почти 2000р в неделю, на симке мегафон, пере подключаясь к серверу. Как мне сказали в "мегафон", кто то ФИЛЬМ смотрел с этой симки! :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 16 ноября, 2012 Опубликовано 16 ноября, 2012 · Жалоба Кстати, по поводу Мегафона и UDP. Было дело, что именно в роуминге (внутрисетевом) бились пакеты UDP. Причем CRC UPD пакета было верно, но данные искажены (либо отсутсвовала часть). Сделал вывод, что кто-то по пути перепаковывает пакет.... По TCP, когда использовали, давно еще, тоже заметили, что с некоторыми операторами SEND OK (SIM300) приходит быстрее, чем сервер принял данные. Значит, ACK на пакет отправляет маршрутизатор ОПСоСА. И гарантированной доставки пакета до сервера нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xmega 0 16 ноября, 2012 Опубликовано 16 ноября, 2012 (изменено) · Жалоба Всем огромное спасибо кто участвовал и давал советы! Так же спасибо поддержке Quectel, правда их советы мне не сильно помогли но... они старались! Как говорится спасение утопающего дело рук самого утопающего, на том и держимся. Текущая ситуация такая: Просматривая документы обратил внимание что модем SIM900 поддерживает GPRS multislot class 10 максимум, а Quectel M10 GPRS multislot class 12. Действительно в настройках Quectel M10 можно понизить GPRS multislot class но там стоит по умолчанию 12!!! что такое GPRS multislot class можно почитать тут : http://ru.wikipedia.org/wiki/%D0%9A%D0%BB%...1%81%D1%8B_GPRS В итоге если понизить GPRS multislot class до 10 или лучше 8 то ВСЕ РАБОТАЕТ! УРА!!! Конечно может радоваться рано потому как тестирую всего 5 часов, но уже четкий результат виден. Так же допускаю, что это косвенно связано и до конца не лечит болячки TCP стека. При установлении сессии оборудование договаривается о количестве слотов, т.е. устанавливается доступный режим, по всей видимости класс 12, но при фактическом использовании такого количество слотов, у модема начинаются проблемы с обменом и по всей видимости это сказывается на работе стека TCP. Что примечательно с понижением GPRS multislot class до класса 8 модем быстрее отправлет т.е. вообще махом задержек практически нет, вот такой парадокс, понизил скорость и стало работать ЕЩЁ БЫСТРЕЙ! Изменено 16 ноября, 2012 пользователем xmega Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
