reset TCP connections to *.microsoft.com
Anyone else experiencing trouble connecting various microsoft www and ftp sites? I put a Sniffer on the line and found that I have a part of a web page come up and then the connection is reset. This is using Netscape Communicator4 on both NT and SPARC Solaris. If one uses IE3 it works better. I find this highly suspicious. Also straight ftp from a unix system is very slow if you get in at all. I think we can all agree that the tcp/ip stack on sparc solaris 2.5.1 is not likely broken (patched to current level, January '98, just in case) where NT might be suspect even 4.0 w/service pack 3. One possible problem I consider is that I have Path MTU discovery turned on in all my routers interfaces (Bay RS12.10). My path to microsoft is via Alter.Net . The local Ethernet MTU is 1518 but the UUNET circuit is 1600. The packets I see come by with "don't fragment" set for several and then one that does not have DF and then the TCP reset comes in. Suggestions and opinions? Thanks Dana Hudes Graphnet
Mr. Dana Hudes <dhudes@graphnet.com> writes:
Anyone else experiencing trouble connecting various microsoft www and ftp sites? I put a Sniffer on the line and found that I have a part of a web page come up and then the connection is reset. This is using Netscape Communicator4 on both NT and SPARC Solaris. If one uses IE3 it works better. I find this highly suspicious. Also straight ftp from a unix system is very slow if you get in at all. I think we can all agree that the tcp/ip stack on sparc solaris 2.5.1 is not likely broken (patched to current level, January '98, just in case) where NT might be suspect even 4.0 w/service pack 3.
This curious behavior was discussed a few months ago on the mailing list for the TCP implementors mailing list. The Windows TCP/IP stack appears to use RST to mean "busy, try again". Unfortunately, no one else does, nor is this behavior needed. An NT machine (presumably what is running on Microsoft's www and ftp sites) will issue an RST on an incoming connection when the socket queue is full. An NT machine acting as a client retries a SYN responded to by an RST 3 times, separated by a half-second, and only then gives up. The proper behavior would be for NT to ignore SYNs when its backlog is full, and rely upon the client machine to retry the SYN. No other TCP/IP stack but Microsoft's is going to retry a connection which was terminated with an RST, so you will likely end up with broken images on a web page. It's possible that IE3 handles this situation better than Netscape because, knowing this quirky behavior, it might attempt to compensate for it by retrying a connection refused a few times. -- Jennifer Dawn Myers <jdm@enteract.com> TCFKASNI http://www.enteract.com/~jdm/
Mr. Dana Hudes <dhudes@graphnet.com> writes:
Anyone else experiencing trouble connecting various microsoft www and ftp sites? I put a Sniffer on the line and found that I have a part of a web page come up and then the connection is reset. This is using Netscape Communicator4 on both NT and SPARC Solaris. If one uses IE3 it works better. I find this highly suspicious. Also straight ftp from a unix system is very slow if you get in at all. I think we can all agree that the tcp/ip stack on sparc solaris 2.5.1 is not likely broken (patched to current level, January '98, just in case) where NT might be suspect even 4.0 w/service pack 3.
This curious behavior was discussed a few months ago on the mailing list for the TCP implementors IETF working group. The Windows TCP/IP stack appears to use RST to mean "busy, try again". Unfortunately, no one else does, nor is this behavior needed. An NT machine (presumably what is running on Microsoft's www and ftp sites) will issue an RST on an incoming connection when the socket queue is full. An NT machine acting as a client retries a SYN responded to by an RST 3 times, separated by a half-second, and only then gives up. The proper behavior would be for NT to ignore SYNs when its backlog is full, and rely upon the client machine to retry the SYN. No other TCP/IP stack but Microsoft's is going to retry a connection which was terminated with an RST, so you will likely end up with broken images on a web page. It's possible that IE3 handles this situation better than Netscape because, knowing this quirky behavior, it might attempt to compensate for it by retrying a connection refused a few times. -- Jennifer Dawn Myers <jdm@enteract.com> TCFKASNI http://www.enteract.com/~jdm/
participants (3)
-
jdm＠joshua.enteract.com -
Jennifer Dawn Myers -
Mr. Dana Hudes