Broken pipe after Modbus TCP/RTU gateway reboot
libmodbus version
3.1.6-2.1
OS and/or distribution
Debian 12.4
Environment
x86-64
Description
My application runs in a Debian VM and communicates with a few RTU slaves through the MikroTik KNOT TCP/RTU gateway (running RouterOS 7.14beta3 or later, as older versions have a bug, missing last byte of response when reading two registers and 2nd byte of response CRC is zero). When that device is rebooted, my application stops working until restarted.
Actual behavior if applicable
After the TCP connection is broken (by the TCP/RTU gateway reboot, network issues etc.), each subsequent modbus_read_registers / modbus_read_input registers returns with EPIPE (Broken pipe) error. To recover, the application needs to be restarted - even though it does use modbus_set_error_recovery(ctx, MODBUS_ERROR_RECOVERY_LINK | MODBUS_ERROR_RECOVERY_PROTOCOL) on startup.
Expected behavior or suggestion
Reconnect to the TCP/RTU gateway automatically, without need to restart the application.
Steps to reproduce the behavior (commands or source code)
Read any registers from some RTU slave(s) through a TCP/RTU gateway repeatedly in a loop, works fine for some time, then reboot the gateway, no longer works and never recovers from the "Broken pipe" error, the application needs to be restarted.
我也遇到相似问题,issue:https://github.com/stephane/libmodbus/issues/734 ,因为我发送的频率很快,断网后,内核缓存溢出很快,就会有Broken pipe错误。我测试过,断网后,调用的send函数依然会发送成功,导致断网重连不起作用。我换了种思路,modbus是一问一答,既然断网时问是成功发送的(实际发送到网络硬件了),但是答确不是。我通过多次接收不到回答数据,便认定断网,关闭socket,然后执行connect,这种思路类似于心跳,但挺好使,希望对你有用。
This issue doesn't help me to understand the problem. Let's see if #734 is more helpful.
The issue with RTU could have been explained by 9fb02835fdb69ec2da81914771256794b9f40482