Date: Tue, 17 Jul 2007 16:47:30 -0700 From: Chuck Swiger <cswiger@mac.com> To: Julian Elischer <julian@elischer.org> Cc: Julian Elischer <julian@ironport.com>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Wierd networking. Message-ID: <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> In-Reply-To: <469D4FB6.9040609@elischer.org> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ I'm not sure which email address I should use when you reply to yourself using a different addy. :-) ] On Jul 17, 2007, at 4:24 PM, Julian Elischer wrote: > Julian Elischer wrote: >> I have been looking at the following snippet of packets (under >> FreeBSD 6.1). >> This makes IE7 fail (but not IE6) with a generic error. >> We see lots of strange things here.. (like, why does the RST >> go to a different sequence number?) > > figured that one out... it's using the latest ACK value from the > client.. Sort of; the 2-byte push from 10.251.22.29.1121 ACKs the sequence # of the Squid box before it sends out the 1460-byte packet (ie, 3799409121): % tcpdump -nS -r IE7.pcap reading from file IE7.pcap, link-type EN10MB (Ethernet) 18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win 32120 18:24:41.313995 IP 10.251.22.29.1121 > 172.28.15.82.3128: P 1573162290:1573162378(88) ack 3799409121 win 65535 18:24:41.314015 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162378 win 33492 18:24:41.314072 IP 172.28.15.82.3128 > 10.251.22.29.1121: . 3799409121:3799410581(1460) ack 1573162378 win 33580 18:24:41.314080 IP 172.28.15.82.3128 > 10.251.22.29.1121: P 3799410581:3799410861(280) ack 1573162378 win 33580 18:24:41.314118 IP 172.28.15.82.3128 > 10.251.22.29.1121: F 3799410861:3799410861(0) ack 1573162378 win 33580 ...at this point, the client should have received the above packets and ACK for 3799410862 to include the FIN. 18:24:41.314744 IP 10.251.22.29.1121 > 172.28.15.82.3128: P 1573162378:1573162380(2) ack 3799409121 win 65535 ...instead it sends an ACK for earlier traffic. The Squid box should be in FIN-WAIT-1 and simply ignore this as a dup ACK, rather than sending an RST: 18:24:41.314767 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799409121:3799409121(0) win 0 18:24:41.315245 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410581 win 65535 Here the client ACK's the 1460-byte packet, and gets another RST. 18:24:41.315262 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410581:3799410581(0) win 0 18:24:41.315369 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 ...and here the client ACK's the 280-byte packet plus the packet with the FIN; it should be sending a FIN here to move both sides to CLOSING state... 18:24:41.315384 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 18:24:41.315619 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 18:24:41.315622 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 18:24:41.315642 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 18:24:41.315650 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 18:24:41.315744 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 18:24:41.315769 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 ...and the rest of this is the client sending ACKs, and the Squid box generating spurious resets each time, when it should be in TIME-WAIT for 2 * MSL. >> What we are having problems with is: >> What SHOULD the server be doing in response to the extra 2 bytes >> it receives after it has sent the FIN? >> I would LIKE to be able to make this work, but I don't personally >> have the influence to fix IE7 so I'm left to do what I can on the >> server (port 3128) end. >> The FIN from the server is generated when the server closes the >> socket. > > note: IE7 never sends a FIN. (IE6 does) That seems very bizzare; does the version of IE really affect the TCP/ IP networking layer? -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37>