Олег

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

Интересное наблюдение: разместили за одной точкой два одинаковых 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 обеих точек прописан в бридж статикой...

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

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

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

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

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

Еще сделал параметры в 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-контоллере, как до него добраться, где изменить.

По этой теме: задержки в потоке данных были на стороне опрашивающего сервера, в этом сознались разработчики ПО опроса, они как-то неправильно копили данные и собирали большой буфер, данные могли скапливаться на период до 3 минут! Но действительно буфер очищался, когда MOXA перезагружали, дело было в закрытии TCP-сессии. Так что тут вопрос снят.

Преобразователь 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 наземными точками вай-фай.

Я тоже первым делом подумал на беспроводную сеть, НО!!! не может же так избирательно тормозить в общем Ethernet-потоке именно канал Port2 ? Если бы возникли проблемы на уровне вай-фай, то тормозить начала мы вся MOXA целиком, по обоим портам сразу! Кроме того я бы и не ее веб-интерфейс попадал бы с той же самой задежкой (а я повторюсь она доходит до нескольких секунд)! Но на веб-интерфейсе задержек нет.

Хм... непонятно что сработало но пока запаздываний нет. Вообще сделали еще заземление самой MOXA (привинчена клемма в районе антенны, как указано на фото в качестве примера). В данной модели есть программное подавление помех? Может быть было большое количество помех, которое как-бы "забивало" чип и он тормозил ? Как только возникнет запаздывание, попробую прекратить/возобновить опрос со стороны сервера и отпишусь по результатам. Кстати MOXA работает в режиме TCP server. Еще уточнение: MOXA своим Ethernet портом смотрит на Wi-Fi точку, которая работает в режиме бриджа и выходит в местную Wi-Fi сеть на 2,5 Ггц. Т.е. опрос идет по Wi-Fi, может ли кратковременное пропадание сигнала по Wi-Fi вызывать такие торможения MOXA ? Хотя я лично пинговал точку и в момент запаздывания не фиксировал пропаданий связи

Со стороны Ethernet так проверять не приходилось (устройство далеко, на высоте 25 метров, к нему не набегаешься по пожарной лесенке чтобы провода дергать). Тут еще уточнение - данные начинают задерживаться обычно только по одному из двух портов (редко по двум сразу), т.е. по второму то все ОК. Саму MOXA перезагружаем через её web-интерфейс только

TAGGB1104895P

К NPort 5250A подключены лазерные дальномеры по COM-порту через RS422, на стандартной скорости 9600 (Port1 и Port2). После подачи питания на MOXA в течении какого-то времени процесс передачи данных в Ethernet идет нормально, затем по одному из портов Port1 или Port2 возникают задержки в передаче данных. Данные из дальномера начинают передаваться с задежкой (до 5 секунд). Лечится перезагрузкой MOXA через web-интерфейс. Собираюсь применить скрипт для удаленной перезагрузки MOXA через планировщик Windows с интервалом раз в час. Но это костыль, который будет мешать. Что пробовал менять: в разделе Main menu - Operation setting - Operation Modes менял параметр Force transmitt c дефолтного нуля на 3 мс, а параметр TCP alive check time убрал значени в ноль (никогда не засыпать). Обновил прошивку с версии 1.2 до версии - 1.4 Build 17030709. Подскажите что еще можно попробовать, а также можно ли и как (чем) проанализировать что именно происходит в MOXA (как включить логирование, можно ли снять данные с MOXA через SNMP и поможет ли)

Добрый день! Просьба выслать утилиту/скрипт для перезапуска устройств серии NPort NPort 5250A