TCP Halts on both NICs if DHCP goes offline

[Mads]

cFP-2220s running LVRT 2011 / Fieldpoint 6.0.9. do not seem to handle loss of contact with the DHCP server *after* bootup.

I have the "Halt on TCP failure"-settings unchecked, and, if the DHCP server is offline when the controller boots, it behaves fine; it starts the RT-application.

However, if the DHCP server is online when the controller boots - but later goes offline, things get messy. Instantly the controller becomes unresponsive on the primary ethernet port. The secondary ethernet port will continue to serve active TCP/IP sessions, but only until these are closed; it will be unresponsive to new connections. This frozen state lasts until the DHCP server on the port 1 network comes back on - then both port 1 and port 2 function again.

One might argue that halting things on port 1 is reasonable (but not practical...), but port 2 is using static IPs (only mode it supports) and should not be affected at all. Loss of communication there just because port 1 lost contact with the DHCP server?? Is that the intended behaviour? Is there a way around it?

[nathand]

Out of curiousity, is your DHCP server providing other services (I'm thinking DNS in particular) as well?

[Mads]

The DNS goes offline too yes, and the gateway. 

The TCP listeners are set to *not* resolve the address, so it should not hang on DNS lookups ((the RT application serves modbus connections on port 502 and a proprietary protocol on port 64000) .

The lack of gateway should not be an issue either as the incoming connections originate from the local subnets of each port.

[Mads]

The DNS comment pointed me in the right direction.

One of the TCP/IP based server interfaces in my application ran an IP to name function. This would then freeze that server on both ports...AND - unexpectedly - freeze all current sessions on other TCP/IP ports as well. 

Should not RT be designed to behave more robustly? A loss of DNS on port 1 should not affect traffic on port 2, regardsless of the use of address resolution? I guess it's handled at different levels though so isolating NIC2 might be difficult?