Home/ Questions/Q 6033495
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T05:29:28+00:00

Resolution, of sorts The client computer that was showing this problem had Trend Micro

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?

    • 0