Modbus Flex Server stops listening after ethernet link fails
WhiteSage opened this issue · 9 comments
Which node-red-contrib-modbus version are you using?
5.23.1
What happened?
After the ethernet link fails there is a random chance that the Modbus Flex Server stops listening to the designated port without error or any kind of warning. This was tested on a raspberry pi by directly disconnecting the ethernet cable and approximately half of the time this would happen.
Server
None/This is related to a node that doesn't connect to a server
How can this be reproduced?
Set up a flex server node on the machine IP static address and any port (let us say 11502). It can be seen the server is listening on the port by running on a linux platform
netstat -tnlp | grep :11502
After disconnecting for ~4 seconds the ethernet cable and reconnecting it there is ~50% chance that the node will stop listening, by shown by the above command, while it still shows up as active on NodeRED.
I am not able to test it on any other machine at the moment, I would appreciate feedback on reproducibility.
What did you expect to happen?
The node should issue the underlying net.Server to listen again on the port (maybe in response to a 'close' event?)
Other Information
Platform: raspbian on raspberry pi 4B
Node-RED version: 3.0.2
NodeJS version: 16.17.0
+1
same issue, rpi cm4
22 Sep 06:33:42 - [warn] [modbus-flex-server:80539e834e9c8d45] Error: This socket has been ended by the other party
22 Sep 06:33:45 - [error] [modbus-flex-getter:c673953e.4b3658] Error: Port Not Open
22 Sep 06:33:47 - [error] [modbus-flex-getter:c673953e.4b3658] Error: Client Not Ready To Read At State reconnecting
22 Sep 06:33:48 - [error] [modbus-flex-getter:c673953e.4b3658] Error: Client Not Ready To Read At State init
I solved this issue by running a simple modbus tcp server in python and after I take the data from it via getter node. Everything works perfectly
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.
If one has access to the underlying machine, a possible workaround is setting up a periodic cron script which restarts the flows
if [ -z "$(netstat -tnlp | grep :11502)" ]; then
node-red-restart > /dev/null 2>&1
fi
I have been using it for months with no issues, but I would appreciate a proper solution. I do not have the NodeJS/NodeRed knowledge needed to provide a fix, and sadly neither the time to learn more.
If the socketError raises in the server, then it should go ahead if it is possible. If in that second try something goes wrong, which is not in the socketError event to fire, then the server is down for now. I think it needs a state machine and some timer to control the state of the server and to be sure in what is to do for the moment. I see this in v6.x for now.
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.
NodeRED version 3.0.2, node version 18.7.0, node-red-contrib-modbus version 5.25.0.
I am also seeing this issue if a Modbus client is terminated or fails. The Modbus Flex Server responds with an error message in NodeRED debug window: "Error: read ECONNRESET"
I have to restart NodeRED to get the socket listening again. Would be nice to have a fix.
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.