Так, понятно.
В логе видно:
15:29:40.725 setting device register: <modbus-tcp:1:holding: 389> ← 254
15:29:40.725 <192.168.10.51:502>. Skip enabling events for modbus:1 ...
15:29:40.727 192.168.10.51:502: Write: 00 01 00 00 00 06 01 06 01 85 00 fe
15:29:40.727 device modbus-tcp:1 is disconnected
15:29:40.727 failed to write: <modbus-tcp:1:holding: 389>: socket closed
Запрос корректный: transaction id 0001, unit 1, функция 06, регистр
0x0185 = 389, значение 0x00FE = 254. Важно, что transaction id = 1 и прямо
**перед записью** идёт строка про enabling events, признак что TCP-
соединение было только что открыто заново, и первая же транзакция в нём
падает. Причём "socket closed" приходит через 2 мс после попытки записи, то есть это
не таймаут ожидания ответа, а разрыв соединения, возможно ответ RST от шлюза.
Предположу: шлюз закрывает сессию сам (по своему таймауту простоя либо
потому, что упёрлись в лимит одновременных TCP-подключений), а на попытку
переоткрыть её отвечает сбросом. Чтобы это подтвердить нужна проверка.
Дамп трафика с контроллера в момент отвала. Запустите на контроллере:
tcpdump -i any -n -s 128 -C 10 -W 3 -w /mnt/data/arlight51.pcap host 192.168.10.51 and port 502
Дайте ему поработать, воспроизведите отвал, остановите (Ctrl+C) и приложите
файлы /mnt/data/arlight51.pcap*. В дампе сразу будет видно, кто и в какой
момент шлёт FIN/RST относительно последнего успешного обмена.
2. Состояние сокетов в тот же момент. Запустите с предыдущей командой одновременно:
while true; do date +%T; ss -tan state all '( dst 192.168.10.51 )'; sleep 2; done | tee /mnt/data/ss-51.log
Опрос регистра сервис может остановить если выполняется что-то из условий - нужно понять что.
Так, понятнее уже.
arlight51.pcap0 сходится по таймингу с ss-51.log:
15:08:52.605 .51:502 → .11:45182 [FIN,ACK] ← шлюз сам закрывает сессию
15:08:52.609 .11:45182 → .51:502 [ACK] ← WB подтверждает FIN, свою сторону НЕ закрывает
... 25 секунд ничего не происходит, сокет CLOSE-WAIT на контроллере
15:09:17.676 .11:45182 → .51:502 [PSH,ACK] len=12 00 01 00 00 00 06 01 06 01 85 00 fe
тут контроллер отправляет в закрытый сокет
15:09:17.676 .51:502 → .11:45182 [RST,ACK] ← +149 мкс, сброс
Шлюз отвечает RST
15:09:17.676 .11 → .51 [FIN], .51 → .11 [RST]
15:09:17.760 новый сокет .11:37990 → .51:502 [SYN/SYN-ACK/ACK] соединение успешно
Видно в
15:09:12
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
CLOSE-WAIT 1 0 192.168.10.11:45182 192.168.10.51:502
15:09:14
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
CLOSE-WAIT 1 0 192.168.10.11:45182 192.168.10.51:502
15:09:16
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
CLOSE-WAIT 1 0 192.168.10.11:45182 192.168.10.51:502
15:09:18
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
ESTAB 0 0 192.168.10.11:37990 192.168.10.51:502
15:09:20
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
ESTAB 0 0 192.168.10.11:37990 192.168.10.51:502
15:09:22
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
ESTAB 0 0 192.168.10.11:37990 192.168.10.51:502
15:09:24
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
ESTAB 0 0 192.168.10.11:37990 192.168.10.51:502
15:09:26
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
ESTAB 0 0 192.168.10.11:37990 192.168.10.51:502
15:09:28
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
ESTAB 0 0 192.168.10.11:37990 192.168.10.51:502
Что с 15:09:18 адрес порта поменялся.
А сам сервис при пересоздании сокета не использует его (почему-то).
В общем уже примерно понятно, попробую синтетически воспроизвести.
Да, для этого шлюза какой-нибудь регистр опрашивается, постоянно? Или только на запись все работают?
Включите какой-то для опроса.