[ 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
