Недоступность порта OnCell 3150

[Геннадий]

Сервер сбора данных с удаленных объектов установлен на сервер на Windows 2012 (64bit). Происходит случайная потеря связи с обеъектом.

При активном соединении с моксой (наблюдаемом при помощи утилиты TCPView) порт становится недоступен (не открывается).

Перезапуск службы драйвера решает эту проблему. Версия драйвера 1.6 build 10071919. Режим Reverse RealCOM.

[Незнайка]

Здравствуйте!

А что значит "при активном соединении"? Можно получить какой то лог обращений к tcp-порту?

[Геннадий]

Активное - значит наблюдаемое в утилите TCPView со статусом ESTABLISHED, причем по обоим используемым портам. Насчет трафика по данным соединениям ничего не известно

[Алексей_]

Здравствуйте, Геннадий!

 

Попробовал аналогичную связку. Данные передавались через RS-232 на скорости 115200 в режиме Reverse RealСom. При принудительном обрыве связи и последующем ее восстановлении через некоторый отрезок времени, соединение восстановилось (с задержкой 2-3 сек.), передача продолжилась. Данные в этом случае переданы корректно.

 

Может в Вашем случае проблема возникает из-за отсутствия передаваемых данных?

[Геннадий]

Дело не в обрывах связи. Связь, конечно, не ахти, то и дело рвется, к тому же на моксах активирован Garanlink, перезапускающий моксу в случае потери контакта с провайдером (по пингу, отсутствию траффика и еще чему-то, короче, по максимуму), так что обрывы это обычное дело. Опрос приборов производится постоянно, данные нужны в реальном времени. Дело в том, что в какой-то момент времени (спустя сутки или неделю) порт просто становится недоступен, т.е. не открывается, хотя мокса на связи. Стоит перезапустить службу драйвера, и порт оживает. Такое ощущение, что в драйвере теряется связь между МАС-адресом моксы и номером порта. Почему такое происходит неизвестно. Может дело в частоте обрывов связи - из 20 подключенных приборов некоторые ни разу не подвисали, а некоторые раз за разом.

[Timoshuk]

Здравствуйте!

Геннадий, Вы используете устаревшую версию OnCell Driver Manager. Попробуйте установить последнюю версию NPort Driver Manager (она работает и с модемами OnCell). Также уточните, пожалуйста, какой версии прошивка в Ваших модемах?

drvmgr_setup_Ver1.17.3_Build_14091615.7z

[Геннадий]

Добрый день!

Попробовали поставить указанный драйвер, но ничего не вышло. Порты для ReverseCom открылись (присутствуют в списке TCPView со статусом LISTENING), но модемы к ним не коннектились (или может коннектились и сразу отбривались) Кроме того импорт конфигурации из OnCell произошел не корректно (строка МАС-адреса не была разделена на байты, хотя судя по остальным опциям, все-таки был установлен режим Reverse RealCOM), однако порт, добавленный вручную, тоже не работал, скорей всего по той же причине (не было соединений от модемов).

В списке доступных устройств, указанных в файле Versions модем OnCell G3150 отсутствует.

Когда вернули все на OnCell сразу все модемы подсоединились.

Что насчет прошивки - некоторые с V2.5, некоторые V3.0. Драйвер OnCell тоже уже проапгрейдили до 1.10 с тех пор уже один раз сбойнуло.

[Геннадий]

Все-таки заставили драйвер заработать, оказалось, что отличаются порты по-умолчанию для Reverse RealCOM - в OnCell 63950 и 63966, а в NPort 60950 и 60966. Кроме того пришлось поправить файл экпорта конфигурации - разделить байты МАС-адреса двоеточиями. Так что вроде все заработало, Сейчас будем ждать сбоев, если будут конечно.

[Геннадий]

Проблема осталась. Опять отвалился рабочий порт. При попытке открыть его сразу дает дает ошибку 5 - ERROR_ACCESS_DENIED (по функции GetLastError), в то время как попытка открыть порт с отсутствующим соединением занимает длительное время и завершается ошибкой 1450 - ERROR_NO_SYSTEM_RESOURCES. Перезапуск соответствующей службы (Nport Secure Service) решил проблему - порт начал открываться.

[Незнайка]

Здравствуйте!

К сожалению, не знаю, что тут ещё посоветовать. Дело в том, что у нас это проблема не воспроизводится (пробовали различными способами). Вероятно, это какая то особенность, связанная с передачей данных конкретно у оператора.

Тут даже нельзя однозначно утверждать, что проблема кроется именно в драйвере MOXA. Ибо точно так-же, можно предположить, что это "подвисает" стек протокола TCP в ОС.

Ещё, я бы добавил, что в данном случае, мы пытаемся решить не проблему, а следствие. То есть проблема в нестабильной работе канала связи, а следствием из неё (предположительно) является многократное переобращение к TCP порту. И говоря другими словами - если многократно что-то "дёргать" - то есть шанс это "задёргать".

Может быть, есть какой то не столь затратный способ улучшить качество связи (например, установив антенны с большим коэффициентом усиления), или произвести смену оператора (хотя-бы в целях диагностики)?

[Геннадий]

Оператор менялся, причем кардинально - все приборы с одного оператора перевели на другого (но не по этим причинам), но зависало как на одном так и на другом. Соединение от моксы тоже существует - если бы мокса не могла соединится, это было бы видно. Так что на ТСР тоже грешить не стоит. А если при попытке открыть рабочий порт система выдает не задумываясь ни на секунду ERROR_ACCESS_DENIED, то это напрямую указывает на драйвер порта. То есть до проверки наличия соединения даже не доходит. Согласен, проблема носит случайный характер, у нас на опросе стоит 20 приборов и с момента обновления драйвера до сбоя система проработала почти неделю. Так что ловить ее надо или специальными закладками или дедуктивным методом по внешним признакам. Насчет качества связи - у нас и так стоят антенны с усилением, но дело в том что порт не открывается при НАЛИЧИИ связи, а такого не должно быть.

[Незнайка]

Здравствуйте!

Попробовал "поймать" проблему долговременным тестированием - используя модуль ввода-вывода разрывал Ethernet - соединение каждые 30 секунд и через 5 секунд восстанавливал обратно (размыкая-замыкая проводники). Данные передаю по RS-232 (генератором случайного набора символов, в одну сторону, от модема к компьютеру), режим работы - Reverse RealCOM. Результат пока никакой - с понедельника всё работает корректно. К сожалению, дальше продолжить наблюдение нет возможности.

Про стек TCP- Вы были правы - дело не в нём. Обдумывал поведенческую модель, и вот что придумал:

1. Сменить TCP порт. Нет ли вероятности того, что какое либо иное приложение не пытается использовать (периодически) его в своих целях?

2. Очевидно, что Вы используете программу опроса. На постоянной ли основе она открывает виртуальный COM-порт? Или открыли-опросили-закрыли? Не исключаю вариант, что в случае, если программа занимает порт на постоянной основе, она не позволяет драйверу произвести некую "реконфигурацию" внутри себя.

3. В конце концов, на этом драйвере свет клином не сошёлся. Если именно он вдруг перестаёт работать на Вашей конкретной конфигурации - почему бы не поискать альтернативный? Например, схожим функционалом (если я не ошибаюсь) обладает программа VSPE, например.

[Геннадий]

1. Насчет порта - врядли, в системе крутится ограниченное число приложений, кто что использует известно, но насчет интернета сказать не могу, оттуда кто угодно может прицепиться куда угодно. Но все-таки порты 63950 и 63966 весьма далеки от стандартных, чтобы кто-нибудь мог к ним еще коннектиться.

2. Порт открывается на постоянной основе, но при отстуствии ответа от опрашиваемого прибора периодически его переоткрывает. Вполне вероятно что сбой происходит в момент удержания порта.

3. В приципе этот драйвер (NPort Driver Manager) работает куда стабильнее родного - сбой происходит примерно раз в неделю. Хотя, конечно, можно поискать и альтернативные варианты.