From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 23:47:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6955E16A402 for ; Tue, 17 Jul 2007 23:47:32 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5078613C4BB for ; Tue, 17 Jul 2007 23:47:32 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id 38A60C47863; Tue, 17 Jul 2007 16:47:32 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 1D42E29C002; Tue, 17 Jul 2007 16:47:32 -0700 (PDT) X-AuditID: 11807123-a5f3ebb000000b34-05-469d55137015 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id EA0D930400C; Tue, 17 Jul 2007 16:47:31 -0700 (PDT) In-Reply-To: <469D4FB6.9040609@elischer.org> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 17 Jul 2007 16:47:30 -0700 To: Julian Elischer X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 23:47:32 -0000 [ 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