Resolution, of sorts
The client computer that was showing this problem had Trend Micro Security installed. This security suite placed a service or driver on top of each network adapter in the system. I did not bother to debug further once this legacy app started working again.
Update 1
I disabled TCP window scale auto-tuning on Win7.
On Windows 7 if I unplug the ethernet cable directly connected to the server, the disconnection happens after about 5 seconds but the client process crashes. netstat on the server reports two TCP connections to the client that are no longer valid, because the client process did not gracefully shutdown and close the connections.
After putting the server in this strange state after the physical disconnect, If I restart the client process it hangs while connecting to the server (just as described in the original)
If I perform a physical disconnection on the XP side, the disconnect happens more quickly than on Win7. Some sort of keep alive value or behavior is different on XP. While ssh'd (via Putty) the ssh connection dies more quickly on XP than Win7 as well.
Original
I have a legacy TCP client/server app that appears to foul up the server only when the client is a Windows 7 machine.
The server is OpenEmbedded Linux running 2.6.11.
A Windows 7 client connects for a bit, and eventually gets to a state where the client disconnects after a second or two.
Once the server is in this state, If I immediately connect a Windows XP client, the XP client cannot connect either.
I cannot appear to get the server into the buggy state by connecting with an XP client alone.
I'd like to know what changes were made to the TCP/IP stack starting with Vista or Windows 7 so I can better debug the legacy code.
I'd also like to know what commands I can run on the Linux server that might better help me understand why the connections are failing.