kia0

Продолжение. В четверг для пробы на временной ВМ обновили версии ядра и драйвера. Ядро 4.1.12 (Oracle Linux UEKR4 4.1.14-124.16.4.el6uek.x86_64), драйвер 4.0.19 Build 210701. Работает без сбоев TCP-соединения (порты 950/966) однократные, далее не обрываются вне зависимости от наличия/отсутствия сигналов с датчика. По порту 4800 udp также присутствует обмен, по пакету в каждую сторону с интервалом ~10-15сек, команда 0x1d с параметрами и ответ в 392 байта, аналогично поведению драйвера 1.19

Удаленно не посмотреть... Есть фото внутренностей резервного датчика, номер NE на нем TAEFB1078210, mac-адрес 00:90:e8:4d:f3:88. Так пойдет?

Посмотрел Ваш дамп. Обмен похож на то, что я наблюдал с версией драйвера 1.19 под ядром 2.6.32: те же регулярные запросы-ответы по порту 4800 UDP. Запрос от npreal2d 24 байта, команда 0x1d (в коде npreal2d.cf этому соответствует ветка "send dsc_GetNetstat_ex" в функции void poll_nport_send(servp)), ответ от NE'шки 392 байта. Но пауз в передаче данных через порт нет,так что тест был "не чистый" Вот одна из NE: Model name : NE-4100T MAC address : 00:90:E8:32:3C:CA Serial No : 1866 Firmware version : 4.1 Build 07061517

Для этого нужно нам попробовать под Fedora Случаем, от Ваших экспериментов tcpdump'ов не осталось, для сравнения? Пока предположения два: какие-то изменения в служебном протоколе обнаружения/мониторинга устройств (UDP 4800), из-за чего старые NE'шки и новый драйвер оказываются несовместимы, и все-таки какой-то баг в npreal2d. Описание протокола в открытом виде есть где-нибудь? Вариант на попробовать: ядро 3.x (например UEK R3 на основе 3.8.13) и драйвер 1.19 Mainline. Но это потребует времени на согласование "окна"...

Анализируя tcpdump, еще заметил разницу: драйвер 1.19 все время обменивается udp-пакетами с NE'шкой по порту 4800, каждые 10-12 сек по паре пакетов. От драйвера 24 байта данных, от NE'шки 392 байта Драйвер 5.1 отправляет по 2 udp-пакета на порты 4800 и 1029 каждые 6-7 секунд по 8 и 6 байт соотв-но и ничего не получает обратно. Такое ощущение, что NE'шка не понимает, что у нее спрашивают Получается, что-то сломано в драйвере между версиями 1.19 и 5.1.

Подняли еще одну ВМ с CentOS 6, ядро Linux 2.6.32-754.el6.x86_64, драйвер npreal2 ver1.19 Build 17110917. Перетащили туда процессы, опрашивающие датчики Отключений tcp-соединений нет, за ~сутки не зафиксировано ни одного из 10шт NE'шек. Комплекс работает стабильно

Печально... Пока прорабатываются вариант вернуть более старую версию драйвера 1.19, на которой все работало до марта, для чего на отдельную ВМ поставить более старую ОС, предварительно RHEL6 с ядром 2.6.32. Далее по результатам.

telnet - view settings: ----------------------------------------------------------------------------- Server name : NE-4100T_8209 Time zone : (GMT+03:00)Moscow, St. Petersburg, Volgograd Local time : 2000/01/26 11:14:43 Time server : Web console : Enable Telnet console : Enable Press any key to continue... ----------------------------------------------------------------------------- IP address : 10.1.1.100 Netmask : 255.255.255.0 Gateway : 10.1.1.254 IP configuration : Static DNS server 1 : 10.1.3.51 DNS server 2 : 10.1.3.52 SNMP : Enable SNMP community name : public SNMP contact : SNMP location : Auto IP report to IP : Auto IP report to UDP port : 4002 Auto IP report period(seconds) : 10 Press any key to continue... ----------------------------------------------------------------------------- Port 1 Baud rate : 9600 Data bits : 8 Stop bits : 1 Parity : None Flow control : None FIFO : Enable Interface : RS-232 Press any key to continue... ----------------------------------------------------------------------------- DIO local TCP port : 5001 ----------------------------------------------------------------------------- DIO 0 Input/Output : Input Control high/low : Low Press any key to continue... ----------------------------------------------------------------------------- DIO 1 Input/Output : Input Control high/low : Low Press any key to continue... ----------------------------------------------------------------------------- DIO 2 Input/Output : Input Control high/low : Low Press any key to continue... ----------------------------------------------------------------------------- DIO 3 Input/Output : Input Control high/low : Low Press any key to continue... ----------------------------------------------------------------------------- Port 1 Real COM Mode TCP alive check time (0-99min) : 7 Delimiter 1 : (Disable) 0 Delimiter 2 : (Disable) 0 Force transmit : 0 Max connection : 1 Press any key to continue... ----------------------------------------------------------------------------- Enable the accessible IP list : Disable 1 Disable 0.0.0.0 2 Disable 0.0.0.0 3 Disable 0.0.0.0 4 Disable 0.0.0.0 5 Disable 0.0.0.0 6 Disable 0.0.0.0 7 Disable 0.0.0.0 8 Disable 0.0.0.0 9 Disable 0.0.0.0 10 Disable 0.0.0.0 11 Disable 0.0.0.0 12 Disable 0.0.0.0 13 Disable 0.0.0.0 14 Disable 0.0.0.0 15 Disable 0.0.0.0 16 Disable 0.0.0.0 Press any key to continue... ----------------------------------------------------------------------------- Mail server : My server requires authenticat : Disable From email address : NE-4100T_8209@NE-4100T Email address 1 : Email address 2 : Email address 3 : Email address 4 : SNMP trap server IP or domain : Press any key to continue... ----------------------------------------------------------------------------- Mail Trap Cold start Disable Disable Warm start Disable Disable Authentication failure Disable Disable IP address changed Disable Password changed Disable DCD changed Disable Disable DSR changed Disable Disable Press any key to continue... ----------------------------------------------------------------------------- DCD changed Port Mail Trap 1 Disable Disable Press any key to continue... ----------------------------------------------------------------------------- DSR changed Port Mail Trap 1 Disable Disable Press any key to continue...

Анализирую сетевые дампы, обратил внимание на 4 факта: 1) Ни одно tcp-соединение на NE'шку не живет дольше единиц минут. Процесс npreal2d (не сама NE!) закрывает их и переустанавливает заново через ~секунду. В этом смысле проверка, как telnet "держит" порт, не даст ничего 2) Если с момента установления соединения, по порту данных (950) нечего не приходит, то npreal2d закрывает и переустанавливает соединение через 30-31 сек 3) Если данные приходят, но потом наступает пауза, то соединение закрывается через ~60сек (иногда 62-63сек) 4) TCP keep-alive опция на сокете данных установлена, keep-alive пакеты ходят, но в отсчетах задержек (2) и (3) не участвуют. Предположение: если в силу работы производственной линии, с датчика "нолик" после "единички" приходит через 60сек, "нолик" попадает на реконнект и теряется. Возможно, линия стала работать чуть медленнее, это и является триггером...

Обновили до 5.1.9, проблема та же Подержать соединение с 950 портом telnet'ом - напомните, при двух параллельных соединениях, данные, принятые через RS232c, пойдут через оба?

Спасибо, попробую

Давайте попробуем npreal2 5.1.9. Как вариант, можно даунгрейднуть npreal2 до 1.19.x, но тогда нужно откатывать ядро ОС на RHEL'овское 3.10.0. И это будет сильно сложнее с административной точки зрения... Сделать тестовый стенд на физике не представляется возможным

Весной (март) был масштабный апгрейд ПО, включая версии ОС и npreal2. Выбор драйвера 5.1.x был обусловлен версией ядра ОС (5.4.17-...). После этого все работало корректно примерно до августа, изменений в составе и настройках ПО, связанного с этими датчиками, не было. Т.е. минимум 4 месяца комплекс устойчиво работал в текущей конфигурации С августа частота сбоев идет по нарастающей, сперва были единичные случаи, которые ошибочно связывали с аппаратными сбоями NE'шек или сети. Сейчас сбои происходят раз в 5-10 минут

Я так понимаю, Verbose logging у npreal2d только через параметр сборки можно включить?

На эту тему мозговой штурм уже был Проекту уже лет 10. Логически на уровне сети и серверов (они виртуальные) все без изменений с конца марта, производство 24x7, изменения согласуются. Часть NE'шек периодически недоступна по сети, т.к. соотв. технологическое оборудование выключается для обслуживания. Но это так всегда было. P.S. С nPort работаем лет 15, стоят на десятках проектов, подобных проблем никогда не было. Пока, кроме запуска npreal2d под отладчиком, других мыслей нет