kia0 Posted November 2, 2022 Share Posted November 2, 2022 Здравствуйте! Технологическая линия, на которой стоят датчики, посылающие одиночные байты ('0' и '1') в RS232c -> NE-4100T -> сеть -> сервер Linux Сами NE-4100T работают корректно, с сетью проблем нет, потерь пакетов нет. tcpdump'ом вижу траффик по настроенным tcp-портам (950 и 966), по порту 950 вижу пресловутые нолики-единички в нужном количестве и порядке. На сервере (Oracle Linux 7, клон RHEL7, kernel 5.4.17-2136.301.1.2.el7uek.x86_64) собран и установлен драйвер вирт. com-портов ver5.1.5 Build 22012618. Запущены демоны npreal2d и npreal2d-redund. С вирт. com-портами работает процесс, постоянно читающий оттуда данные с датчиков и шлюзующих их дальше в прикладную систему. Проблема в том, что периодически данные с датчиков не доходят до вирт. порта: какой-то из байтов теряется, что нарушает логику управления линией. Потерянный байт я вижу по сети, но его нет на com-порте. В момент потери tcpdump'ом вижу переустановление пары TCP-соединений между npreal2d и NE-4100T: демон почему-то закрывает оба коннкета, и через несколько сотен мс открывает их заново. Com-порт при этом остается открытым на чтение. В npreal2d.log иногда в таких случаях фиксируется ошибка "ConnectCheck> Socket connect fail (ip-адрес)". Предполагаю, что потерянный байт погибает в буфере сокета при закрытии соединения. Но почему npreal2d его закрывает??? Весь комплекс корректно работал длительное время, потом начались эти проблемы. Заказчик самостоятельно перезапускал и оборудование, и сервер без результата. Конфиг демона: #=========================================================# # This configuration file is created by Moxa NPort # # Administrator Program automatically, please do not # # modify this file by yourself. # #=========================================================# ttymajor=33 calloutmajor=38 #[Minor] [ServerIP] [data] [cmd] [FIFO] [SSL] [ttyName] [coutName] [interface][mode][BackIP] 0 10.1.1.81 950 966 1 0 ttyr00 cur00 0 0 1 10.1.1.82 950 966 1 0 ttyr01 cur01 0 0 2 10.1.1.83 950 966 1 0 ttyr02 cur02 0 0 3 10.1.1.84 950 966 1 0 ttyr03 cur03 0 0 4 10.1.1.85 950 966 1 0 ttyr04 cur04 0 0 5 10.1.1.86 950 966 1 0 ttyr05 cur05 0 0 6 10.1.1.88 950 966 1 0 ttyr06 cur06 0 0 7 10.1.1.87 950 966 1 0 ttyr07 cur07 0 0 8 10.1.1.89 950 966 1 0 ttyr08 cur08 0 0 10 10.1.1.100 950 966 1 0 ttyr0a cur0a 0 0 Запуск npreal modprobe npreal2 ttymajor=33 calloutmajor=38 verbose=0 /usr/lib/npreal2/driver/mxloadsvr stty -F /dev/ttyr00 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr01 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr02 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr03 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr04 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr05 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr06 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr07 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr08 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke stty -F /dev/ttyr0a 9600 clocal -icrnl ignbrk -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke Демоны запущены с параметром '-t 1' (/usr/lib/npreal2/driver/npreal2d -t 1, /usr/lib/npreal2/driver/npreal2d_redund -t 1). SElinux, iptables и пр. на сервере выключены. Есть трассировка (strace) с демона (много). Есть бинарный tcpdump, снятый на сервере для одного из NE-4100T Link to comment
Знайка Posted November 2, 2022 Share Posted November 2, 2022 Добрый день. Если система длительное время работала, а потом перестала, то логично предположить, что что то изменилось. Как бы узнать, что именно? Link to comment
kia0 Posted November 2, 2022 Author Share Posted November 2, 2022 На эту тему мозговой штурм уже был Проекту уже лет 10. Логически на уровне сети и серверов (они виртуальные) все без изменений с конца марта, производство 24x7, изменения согласуются. Часть NE'шек периодически недоступна по сети, т.к. соотв. технологическое оборудование выключается для обслуживания. Но это так всегда было. P.S. С nPort работаем лет 15, стоят на десятках проектов, подобных проблем никогда не было. Пока, кроме запуска npreal2d под отладчиком, других мыслей нет Link to comment
kia0 Posted November 2, 2022 Author Share Posted November 2, 2022 Я так понимаю, Verbose logging у npreal2d только через параметр сборки можно включить? Link to comment
Знайка Posted November 2, 2022 Share Posted November 2, 2022 Ну смотрите: проекту 10 лет, а драйвер 5.1.5, как я понял, выпущен он 26.01.2022, насколько я могу судить. Точно все изменения логируются? Возможно, ранее использовалась другая версия? Link to comment
kia0 Posted November 2, 2022 Author Share Posted November 2, 2022 Весной (март) был масштабный апгрейд ПО, включая версии ОС и npreal2. Выбор драйвера 5.1.x был обусловлен версией ядра ОС (5.4.17-...). После этого все работало корректно примерно до августа, изменений в составе и настройках ПО, связанного с этими датчиками, не было. Т.е. минимум 4 месяца комплекс устойчиво работал в текущей конфигурации С августа частота сбоев идет по нарастающей, сперва были единичные случаи, которые ошибочно связывали с аппаратными сбоями NE'шек или сети. Сейчас сбои происходят раз в 5-10 минут Link to comment
Знайка Posted November 2, 2022 Share Posted November 2, 2022 4 месяца и 10 лет всё таки существенная разница . А по существу - либо могу предложить "в лоб" попробовать 5.1.9, либо надо устанавливать драйвер на физику, без гипервизоров, напрямую (прямым патч-кордом) сцеплять с NEшкой, и, если всё так же будт воспроизводится - то уже с этого стенда и снимать логи. Остальное всё от лукавого, слишком много промежуточных звеньев. Link to comment
kia0 Posted November 2, 2022 Author Share Posted November 2, 2022 Давайте попробуем npreal2 5.1.9. Как вариант, можно даунгрейднуть npreal2 до 1.19.x, но тогда нужно откатывать ядро ОС на RHEL'овское 3.10.0. И это будет сильно сложнее с административной точки зрения... Сделать тестовый стенд на физике не представляется возможным Link to comment
Знайка Posted November 3, 2022 Share Posted November 3, 2022 https://disk.yandex.ru/d/QIw7w8x7rUC_Ew 5.1.9 тут Link to comment
Знайка Posted November 3, 2022 Share Posted November 3, 2022 Напишите, что получится. И такой ещё интересный вопрос - если открыть соединение с 950 сокетом чем то другим, терминалом каким-либо, то будет ли сессия существовать сколь либо продолжительное время, я к тому, что не будут ли и в этом случе возникать ошибки вида: Socket connect fail (ip-адрес)? Link to comment
kia0 Posted November 8, 2022 Author Share Posted November 8, 2022 Обновили до 5.1.9, проблема та же Подержать соединение с 950 портом telnet'ом - напомните, при двух параллельных соединениях, данные, принятые через RS232c, пойдут через оба? Link to comment
Знайка Posted November 8, 2022 Share Posted November 8, 2022 Да, данные пойдут в оба соединения, но надо помнить, что алгоритмы работы при Max. connection = 1 и 2 несколько отличаются, так что если стоит задача непрерывности процесса получения данных (оборудование в работе), то я бы на нём эксперименты проводить (изменять Max. connection ) не стал Link to comment
kia0 Posted November 9, 2022 Author Share Posted November 9, 2022 Анализирую сетевые дампы, обратил внимание на 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сек, "нолик" попадает на реконнект и теряется. Возможно, линия стала работать чуть медленнее, это и является триггером... Link to comment
Знайка Posted November 10, 2022 Share Posted November 10, 2022 Понял. Я попробую написать разработчикам вопрос, почему драйвер ведёт себя так. Но на такие вопросы обычно отвечают слабо, так что ничего тут обещать не могу. Посмотрим. Link to comment
Знайка Posted November 11, 2022 Share Posted November 11, 2022 Можете ещё файл конфигурации от NE приложить? Link to comment
kia0 Posted November 11, 2022 Author Share Posted November 11, 2022 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... Link to comment
Знайка Posted November 22, 2022 Share Posted November 22, 2022 Добрый день, ну вот дошли и до этого вопроса, комментариев от разработчиков никаких получить не удалось (в общих чертах ответ был таков: сначала покажите проблему, потом мы подумаем), попробовали воспроизвести на Fedora 36 + npreal 5.1.9 + putty, и, как результат -соединение обрывается только при отключении клиента (putty), наличие или отсутствие данных в сессии влияния никакого не оказывает. Так что пока (пока не доказано обратное) я склонен считать, что мы имеем дело с проблемами в визуализации. Link to comment
kia0 Posted November 22, 2022 Author Share Posted November 22, 2022 Печально... Пока прорабатываются вариант вернуть более старую версию драйвера 1.19, на которой все работало до марта, для чего на отдельную ВМ поставить более старую ОС, предварительно RHEL6 с ядром 2.6.32. Далее по результатам. Link to comment
kia0 Posted December 16, 2022 Author Share Posted December 16, 2022 Подняли еще одну ВМ с CentOS 6, ядро Linux 2.6.32-754.el6.x86_64, драйвер npreal2 ver1.19 Build 17110917. Перетащили туда процессы, опрашивающие датчики Отключений tcp-соединений нет, за ~сутки не зафиксировано ни одного из 10шт NE'шек. Комплекс работает стабильно Link to comment
kia0 Posted December 16, 2022 Author Share Posted December 16, 2022 Анализируя 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. Link to comment
Знайка Posted December 16, 2022 Share Posted December 16, 2022 Почему у нас на Fedora не воспроизводится, что мы делаем не так, на ваш взгляд? Link to comment
kia0 Posted December 16, 2022 Author Share Posted December 16, 2022 Для этого нужно нам попробовать под Fedora Случаем, от Ваших экспериментов tcpdump'ов не осталось, для сравнения? Пока предположения два: какие-то изменения в служебном протоколе обнаружения/мониторинга устройств (UDP 4800), из-за чего старые NE'шки и новый драйвер оказываются несовместимы, и все-таки какой-то баг в npreal2d. Описание протокола в открытом виде есть где-нибудь? Вариант на попробовать: ядро 3.x (например UEK R3 на основе 3.8.13) и драйвер 1.19 Mainline. Но это потребует времени на согласование "окна"... Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now