Windows 7 or Vista TCP behavior changes

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开发者_如何学C 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.

Perhaps the best thing you can do is to fire up tcpdump or wireshark under linux and analyze the TCP SYN sent by both Windows XP and Windows 7. Wireshark allows you to break out bit-by-bit what TCP options are sent... for example, this is what you see from a debian lenny box making a TCP connection:

Transmission Control Protocol, Src Port: 58456 (58456), Dst Port: 23 (23), Seq: 0, Len: 0
    Source port: 58456 (58456)
    Destination port: 23 (23)
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 5840
    Checksum: 0x8b77 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        SACK permitted
        Timestamps: TSval 136991740, TSecr 0
        NOP
        Window scale: 6 (multiply by 64)

My suspicion is that you'll see differences in RFC 1323 Window Scaling, but I don't have an XP machine handy to validate this.

I gave a detailed response of how to analyze TCP connections using tcptrace under linux in this answer... How can I measure the performance and TCP RTT of my server code?

I also suspect a Window Scaling issue. I cannot find a link just at the moment, but there were complaints when Vista first came out reporting that that something was screwing with some routers (belkins If I recall). They traced it down to a problem with one of the window sizes that Vista (and thereby Windows 7) changes by default. The routers would get hung up and need to be reset every few minutes.

You can issue some commands to turn off window scaling, see if your problem goes away. From Here:

netsh interface tcp set global autotuninglevel=disabled

Edit:

Try disabling IPv6 on windows 7. Link on how to do that. With IPv4, it should act the same as windows XP. Load up wireshark on the two systems and compare the differences