VMware ESXi 5.5 Windows Server 2012 connected via VLAN with 3 hops (Cisco switches) to Modbus TCP Devices:
Advantech ADAM-5000/TCP (x5) Advantech ADAM-6260 TCP. (x1)
The devices can be polled using the Advantech ADAM/Apax.net utility version 2.05.10.
I'm running Wonderware System Platform 2014 R2 SP1 as the SCADA with DASMBTCP Version 3.0.1 Data Acquisition Server.
The ADAM-6260 device is rock solid and never loses connection.
The ADAM-5000/TCP devices all drop connection via port502 after 7 hours 20 minutes of stable operation.
Pinging the devices is always possible, even after the Modbus TCP port closes.
A physical reset of the ADAM5000 brings the device back to life.
If I connect a Win7 laptop to the Server switch and route through the VLAN to the ADAM 5000, connection is rock solid.
If I connect a Win7 laptop to the ADAM 5000 via cross-over cable the connection is rock solid.
As soon as the device is connected and polled from the VMWare Windows Server 2012, the Modbus TCP fails after 7 hours and 20 minutes.
I've tried using a Telnet client but Port 502 is definitely closed.
The Advantech Utility error message is "Connect Module Failed! Reached maximum number of connections"
The issue seems to be independent of the Wonderware DA Server or the Advantech ADAM/Apax.net Utility because when both are disabled / not polling the devices still drop out after the 7hrs20mins.
The ADAM6260 is solid and Advantech support put this down to a function / feature called "Host Idle Timeout". This is not available on the ADAM5000, although I have requested it.
The table below should help guide through the Wireshark log
I wanted to attach several screenshot of Packet Captures and upload a capture to Cloudshark but I'm unable to due to company policy and I'm unable to add files directly to this post.
Any Guidance or insights would be very much appreciated, I've been working on this issue for 6 weeks now. Many thanks in advance.
asked 13 Apr '17, 03:47
edited 13 Apr '17, 14:51
Working with the brief text excerpt of the capture I can see the following:
In summary, the master sends a requests, the slave fails to respond, the master closes the connection, the slave fails to complete the connection close, the master successfully opens another connection and sends a query to which the slave hard-closes the connection.
Looks to me like an application issue on the slave.
answered 13 Apr '17, 05:22