MOXA Nport и точка доступа Wi-Fi

[Олег]

Преобразователь NPort 5250A работает в режиме TCP Server и постоянно теряется по сети за точкой доступа, работающей в режиме Bridge. У точки адрес динамический, у MOXA статический. Точки разные - Cisco AP2700 и Mikrotik - одинаково себя ведут. Причем если зайти на точку доступа по вай-фаю через putty, то MOXA пингуется, а из самой сети вай-фай нет, если далее по IP зайти на MOXA через командную строку, то вай-файный шлюз с MOXA не пингуется, если через меню MOXA перезагрузить её, то связь восстанавливается. Контроллер вай-фай теряет MAC-адрес MOXA за точкой? Нельзя сказать что MOXA ведет себя слишком тихо и о ней забывают, там Force transmitt = 3 мс. Опрос со стороны сервера идет с частотой 50 мс. Пробовал со стороны опрашивающего сервера прекращать опрос (стоп-старт OPC Server) - помогает, MOXA снова появляется в сети!

Пробовал перезагружать точку доступа вай-фай- не помогает, точка загружается, а MOXA по-прежнему недоступна! Пробовал делать down / up Ethernet-порта от точки доступа до MOXA - не помогает. Помогает только перезагрузка самой MOXA! Со стороны сервера тоже особенность - помогает только останов опроса, с закрытием TCP-сессии до MOXA (убеждаюсь на сервере через netstat -na, что запись о данной MOXA исчезает). 

Пробовал менять частоту опроса со стороны сервера (10....50 мс), пробовал менять следующие параметры в MOXA Operation Setting - Port - Operation Modes:

Packing length - 0, 512,1024
Force transmit вычислил по формуле из документации к MOXA - 3 мс, убрал в ноль TCP alive check time и Inactivity time.

Обновил прошивку до 1.4 Build 17030709, улучшил заземление корпуса MOXA.

Выпросил у Незнайки скрипт для перезапуска MOXA, но, это не решение. Тем более что скрипт сможет сделать свое дело только пока MOXA доступна по сети. Кстати превентивные перезагрузки помогают, но надо их делать раз 10 в день и то иногда MOXA  успевает пропасть и скрипт бесполезен.

Еще одна особенность, если в цеху вдруг пропадает и появляется вай-фай, то примерно 50% устройств MOXA (забыл сказать что их 8 штук вместе с 8 точек доступа) после восстановления связи по вай-фай, за точкой доступа опять теряются, хотя при этом они сами живые, на них опять последовательно через точку доступа заходим через консоль и перезагружаем, после этого работа продолжается (до следующего раза)

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

Питание MOXA нормальное от промышленного БП (стоят на одной DIN-рейке), даже ИБП есть, но правда не Smart и не только ради MOXA, а еще PLC и точки доступа. Заметьте, что я ни разу не написал слово "зависала", потому что MOXA действительно не зависала в привычном понятии.

К слову сказать Wi-Fi в цеху довольно тяжелый  и с точки зрения помех электрических и не очень грамотно расставленых наземных точек, часто точка доступа с большими лагами переключается между наземными точками (бывает 2-3 пинга пропадают). Оборудование расположено на кранах, постоянно перемещающихся по цеху, переключаясь по пути следования между 3 наземными точками вай-фай.

[Олег]

Еще сделал параметры в MOXA:
Max connection = 4
Ignore jammed IP = Yes   (игнорирование некорректных сетевых пакетов)
Allow driver control = Yes  (разрешение управлением драйвером)
MOXA проработали 30 часов бесперебойно и все равно на двух точках (из 8) опять пропали, пришлось перезапускать.

Если поиграться параметром Inactivity time и сделать чуть больше чем Force Transmit и меньше чем период опроса со стороны сервера? Например опрос сервера 10 мс, Force Transmit = 3 мс, тогда Inactivity time пусть будет 5 мс. Я правильно понимаю что этот параметр принудительно закрывает TCP-сессию каждые 5 мс, если по RS-232 нет активности? Или этот параметр ни на что не повлияет в данном случае?

Еще где-то тут читал на форуме, что виной может быть настройка в Wi-Fi контроллере по-умолчанию, которая банит IP адрес, если от клиента идет большое кол-во бродкаст запросов. Может ли MOXA создавать такой трафик и из-за этого попадать в немилость Wi-Fi контроллера? Сам Wi-Fi контроллер находится в зоне ответственности цеховых админов, которые нас в свою кухню не пустят, а разбираться сами по доброй воле не хотят. Смогут лишь посмотреть что-то, если мы им на блюдечке решение приподнесем, с голубой каёмочкой которая. Так вот может кто знает, что это за параметр в Cisco-контоллере, как до него добраться, где изменить. 

[Незнайка]

Не пробовали включать  функцию  IP Address Report с указанием адреса сервера сбора в качестве адреса назначения?

[Олег]

1 час назад, Незнайка сказал:

Не пробовали включать  функцию  IP Address Report с указанием адреса сервера сбора в качестве адреса назначения?

Попробовал сейчас, но похоже там UDP протокол закрыт на ASA Cisco, Nport Administrator на сервере не фиксирует ничего входящего, сервис запущен на стандартном порте UDP/4002, netstat -na показывает что порт прослушивается, но соединений нет. Свой брандмауер на сервере выключен, на точке указал IP адрес сервера. Затем проверил с другого устройства из сети вай-фай доступность порта UDP/4002 утилитой PortQuery - он пишет что порт не прослушивается. В общем не получилось. Буду просить завтра админов открыть UDP между точками и сервером

[Незнайка]

2 hours ago, Олег said:

Попробовал сейчас, но похоже там UDP протокол закрыт на ASA Cisco, Nport Administrator на сервере не фиксирует ничего входящего, сервис запущен на стандартном порте UDP/4002, netstat -na показывает что порт прослушивается, но соединений нет. Свой брандмауер на сервере выключен, на точке указал IP адрес сервера. Затем проверил с другого устройства из сети вай-фай доступность порта UDP/4002 утилитой PortQuery - он пишет что порт не прослушивается. В общем не получилось. Буду просить завтра админов открыть UDP между точками и сервером

Если проблема именно в WiFi Bridge, ближайшему к NPort, то думаю что нет разницы, слушает там сервер или нет. Интервал там установите поменьше, 1 -2 сек.

[Олег]

3 часа назад, Незнайка сказал:

Если проблема именно в WiFi Bridge, ближайшему к NPort, то думаю что нет разницы, слушает там сервер или нет. Интервал там установите поменьше, 1 -2 сек.

Ну да, Вы правы. Чтож, я все равно уже сделал отправку через IP Address Report, как говорится будем посмотреть. 

[Олег]

Отправка  IP Address Report не помогла, несколько MOXA через сутки все равно пропадали за бриджем. Опять спасала только перезагрузка MOXA. Также и не спасает ежечасная! принудительная перезагрузка MOXA через утилиту

[Незнайка]

12 hours ago, Олег said:

Отправка  IP Address Report не помогла, несколько MOXA через сутки все равно пропадали за бриджем. Опять спасала только перезагрузка MOXA. Также и не спасает ежечасная! принудительная перезагрузка MOXA через утилиту

Потому что "теряется" она не на ближайшем Bridge (через него то NPort всегда доступен, получается?), а где то дальше в сети. Когда пропадет, идите по всей цепочки устройств, смотрите наличие и корректность ARP или MAC записей, где то MAC NPort светиться не будет, чудес то не бывает.

[Олег]

11 часов назад, Незнайка сказал:

Потому что "теряется" она не на ближайшем Bridge (через него то NPort всегда доступен, получается?), а где то дальше в сети. Когда пропадет, идите по всей цепочки устройств, смотрите наличие и корректность ARP или MAC записей, где то MAC NPort светиться не будет, чудес то не бывает.

MAC NPort теряется уже на ближайшем бридже. Там как-то все сложно, у клиентской точки есть три интерфейса  - Dot11Radio0, Gi0, BVI. Когда заходим на точку, то MAC NPort на BVI не обнаруживается, он появляется как только начнешь пинговать NPort. Но NPort становится доступным снаружи, только если отправить ICMP пакет в сторону вай-фай шлюза. В любом случае я уже понимаю, что дело не в NPort, а в настройках Wi-Fi контроллера (или может даже самой клиентской точки, которая работает в режиме workgroup-bridge (WGB), нормальную поддержку которого обеспечивает настройка "Aironet IE" на контроллере, скорее всего она не включена. Ну, это предположение)

[Незнайка]

13 hours ago, Олег said:

MAC NPort теряется уже на ближайшем бридже. Там как-то все сложно, у клиентской точки есть три интерфейса  - Dot11Radio0, Gi0, BVI. Когда заходим на точку, то MAC NPort на BVI не обнаруживается, он появляется как только начнешь пинговать NPort. Но NPort становится доступным снаружи, только если отправить ICMP пакет в сторону вай-фай шлюза. В любом случае я уже понимаю, что дело не в NPort, а в настройках Wi-Fi контроллера (или может даже самой клиентской точки, которая работает в режиме workgroup-bridge (WGB), нормальную поддержку которого обеспечивает настройка "Aironet IE" на контроллере, скорее всего она не включена. Ну, это предположение)

Предложу добавить MAC NPort как статическую запись в bridge

[Олег]

В 19.04.2019 в 11:32, Незнайка сказал:

Предложу добавить MAC NPort как статическую запись в bridge

Включили режим Aironet IE на контроллере Wi-Fi и начал нормально поддерживаться режим WGB, для гарантии еще прописали MAC NPort в статику bridge и увеличили время хранения этой привязки aging-time

[Олег]

Интересное наблюдение: разместили за одной точкой два одинаковых NPort.  На первом устройстве настройки: Force transmit = 3 ms, Ignore Jammed IP = yes, TCP alive check time = 0. Второе устройство с настройками по-умолчанию (специально). Так вот в результате мониторинга (каждые 5 сек пинг с логированием) - интересный результат - первое устройство работает с 100% доступностью, а второе устройство за 12 часов вылетело из сети 3 раза - на 3 минуты, на 1,5 и на 15 сек. (Проблемы, которой посвящен пост - нет, т.е. устройства не теряются безвозвратно за бриджем). Сейчас сделал на втором Igmore jammed IP и буду мониторить... И таки да - MAC обеих точек прописан в бридж статикой...

[Незнайка]

Интересное наблюдение..

[Олег]

За сутки вычислил похоже параметр, влияющий на зависание (пропадание) NPort. Сначала сделал Ignore Jammed IP - зависла, потом Force Transmit = 3ms - зависла, потом сделал Auto report to IP (адрес шлюза) и вот уже с утра ни одного пропадания! Погоняю еще пару суток, может подтвердится