Wierd networking.

[Chuck Swiger]

[ 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