Link loss may cause TCP to be half open for a long time

This problem was discovered during the EtherNet/IP Plugfest after consecutive runnings of test P12.10 from EDITT (v1.25.01).

Test Procedure:

• If the device supports an Exclusive Owner connection, establish a class 1 Exclusive Owner connection with the connection parameters below.  If the device does not support an Exclusive Owner connection, establish a class 1 Input Only connection.
  • Cyclic
  • Multicast T->O
  • Unicast O->T
  • 100 msec RPI
  • 4x Timeout Multiplier
• Establish a class 1 Input Only or Listen Only connection from the second host IP address to the same input connection point used above with the same parameters as above.

 

• Open 2 Class 3 connections to the DUT over each of the 3 host IP addresses:
  • Get Attribute Single command to attributes 2 and 3 of instance 1 of the Identity Object.
  • 250 msec RPI

 

• Make sure all connections were established.
• Sustain the connections for a period of 15 seconds, watching for connection failures or timeouts.

 

• Prompt user to disconnect Ethernet cable from DUT.
• Wait 5 seconds after connection loss and Prompt user to reconnect cable.
• Make sure all connections resume.
• Sustain the connections for a period of 15 seconds, watching for connection failures or timeouts.

 

• Prompt user to disconnect Ethernet cable from DUT.
• Wait 30 seconds after connection loss and Prompt user to reconnect cable.
• Make sure all connections resume.
• Sustain the connections for a period of 15 seconds, watching for connection failures or timeouts.

 

• Prompt user to disconnect Ethernet cable from DUT.
• Wait 3 minutes after connection loss and Prompt user to reconnect cable.
• Make sure all connections resume.
• Sustain the connections for a period of 15 seconds, watching for connection failures or timeouts.

 

• Close all connections.

Problem description:

When running P12.10 the test will fail because the DUT runs out of TCP sockets. The reason are half open TCP sockets that are in closing state (performing a 4-way graceful socket close) but didn't received any ACK from the client which in turn causes the socket to stay in a waiting state and open for a long time.
Waiting for several minutes would free these sockets again. However, an end user would not expect a device to behave like that.