ModbusTCPServer - Possibly Locked up

[BobO]

I'm bumping this again to see if those who have installed Version 2.9 have seen this issue resolved (or at least apparently resolved). I've upgraded some of my stuff to 2.9 but haven't had things on long enough to see if there are still comms issues.

I'm curious as well, but we're pretty sure we know what was causing that. With the right test we were easily able to dupe it.

[Mike@Forshock]

So, we are still having this issue on 2.9.6.  Perhaps not as frequent, but it is still interrupting our processes.

Two BRX on 2.9.6 on a licensed radio link (9.6kbps...) using Modbus TCP.  Request is sent every minute, it has had more interruptions due to poor weather.  Causes are not limited to "no reponse", can also add old/non-updated data. 

Additionally, have other units on 2.9.6 with Modbus TCP links over WiFi type radios, that when we get a series of comms fails it stops updating.  These are typicall 10-20Mbps, but do experience a random loss here and there.  These stop responding to update requests from the Master unit.

EDIT:  Only solution is to powercycle or force REBOOT

[BobO]

So, we are still having this issue on 2.9.6.  Perhaps not as frequent, but it is still interrupting our processes.

Two BRX on 2.9.6 on a licensed radio link (9.6kbps...) using Modbus TCP.  Request is sent every minute, it has had more interruptions due to poor weather.  Causes are not limited to "no reponse", can also add old/non-updated data. 

Additionally, have other units on 2.9.6 with Modbus TCP links over WiFi type radios, that when we get a series of comms fails it stops updating.  These are typicall 10-20Mbps, but do experience a random loss here and there.  These stop responding to update requests from the Master unit.

EDIT:  Only solution is to powercycle or force REBOOT

We identified an issue in the TCP stack where unstable radios could cause the listening socket to get hung for a long time, on the order of 20 minutes. If the issue that got us there to start with continued constantly, the socket would appear to freeze indefinitely. The specific condition that causes it is to receive two duplicate TCP SYNC frames, and then the client give up on the connection. It doesn't appear to be as common when the client connects to the server and stays connected, but since many radio remotes are connecting and disconnecting every time they read, it appears to happen more frequently there. This never happens on wired connections, which is why it has been almost impossible for us to duplicate.

We have a fix in beta if you'd like to try it.

[Mike@Forshock]

Kinda already running beta now so... Send it over