TCP close on Class3 connection timeout: Resetting the TCP connection instead of a graceful close

Issue discovered during CT19.1 testing:
When running Ethernet Link object test with security session active and the network cable is directly connected to the DUT(no switch inbetween)

Issue description:
Receiving a new value for attribute 6 of Ethernet Link object(Interface control), EIP stack gives up its IP address and tries to reconfige the phys which takes some few seconds. During this period the stack has no IP address and the used TCP connection is not valid anymore.
CT opens a new connection after ech setting of the interface control, simultaneously any of the previous class3 connections can fall into timout which the stack tries to close the corresponding socket with a 4way close handshake sending a FIN to the client. 
The problem apears when the client (CT) doesn't finish the 4way close handshake and sneds only an ACK in response server's FIN. This behaviour puts all the timedout sockets into FIN-WAIT-2 state which will be cleand up and freed only after 20 seconds.
When CT opens multiple consecutive connections to set interface control of the device, at some point all the possible TCP sockets will be in the FIN-WAIT-2 state although they are supposed to be closed. Only after 20 seconds there will be free sockets to use. 

Solution:
We can use abort (which frees the connection resources immediatly) instead of FIN. I guess it's totally ok to use RST for a timedout connection even if it doesn't seem to be a clean way of closing scokets.