From owner-freebsd-net@FreeBSD.ORG Sat May 14 04:07:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3411F106564A for ; Sat, 14 May 2011 04:07:09 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E30348FC0C for ; Sat, 14 May 2011 04:07:08 +0000 (UTC) Received: by gxk28 with SMTP id 28so1355645gxk.13 for ; Fri, 13 May 2011 21:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rxTRgx92K1Ct5UaJ1JvlkFpd7IbThtzcEAtTNwTk+jw=; b=pIdorZlXPZmUn3ioS3GTvxodvnpK9T2BBegu+siu6u4ryQBxT8aFvzV/BYasx0gS8l LpI+Af0k1PbRH0ZH9/A/k1B3HcNFUR2xY+9ls+sVxrHCHVL1B+3dy2DIPfzwcXmElS4k B8OwOTAGAg3GafTU6UfSJOfSRkQeJzuFMntpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ha/CqosK7ZI4iJCpaWfO0ujFYZ9qwRyzNN2fn/TOvPJTWc0pC8woSqLR21WSVov6R2 cV57Un4U38gLLKV+GFhc/bmFPL1SL4gZDCYnRSJcEffH3wyQU3VokGB+JS19dwrKZ7Od 9yyL9IJ5lLlo0NyCIiBuMYfvzFhwTFNC7NYQo= Received: by 10.101.117.17 with SMTP id u17mr1338560anm.106.1305344429151; Fri, 13 May 2011 20:40:29 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.248.5 with HTTP; Fri, 13 May 2011 20:39:49 -0700 (PDT) In-Reply-To: <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com> References: <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com> From: Ivan Voras Date: Fri, 13 May 2011 23:39:49 -0400 X-Google-Sender-Auth: 1M99IUXmo-O8p3SRh9zoiZnUmUs Message-ID: To: Chuck Swiger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Spurious ACKs, ICMP unreachable? 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: Sat, 14 May 2011 04:07:09 -0000 On 13 May 2011 17:38, Chuck Swiger wrote: > On May 13, 2011, at 1:07 PM, Ivan Voras wrote: >> I'm seeing an an unusual problem at a remote machine; this machine is >> the FreeBSD server, and the client is a probably Windows machine (but I >> don't know the details yet). Something happens which causes FreeBSD to >> send ACKs to the client, and the client to send ICMP unreachable >> messages to the server. It is most likely a configuration error at the >> remote site but I have no idea how to verify this. > > > Let's look at just one connection: > > 18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191, = win 0, length 0 > 18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win 65535= , length 0 > > The packet is FreeBSD webserver sending ACKs with zero window size; that'= s a sign of congestion that the client should not be sending more data and = instead doing periodic window probes until the local box opens the window a= gain. =C2=A0The next packet on the same connection then ACK's something out= side of the window with a 64K window size. =C2=A0That's wrong; the other si= de probably sends an RST and the ICMP error. =C2=A0If you have TSO enabled,= try turning it off. Well the problem is that there is no traffic from the other side that I can see; either it's blocked by ipfw on the server or by something else - both options are not good. Could it be that the ipfw dropped the (dynamic) state for the connections but the TCP stack keeps retrying them and doesn't know when to quit? This is FreeBSD 8-stable under VMWare, without TSO on em. > Otherwise, providing the hex data or the ICMP packet via -x or -X might h= elp identify which connection the Windows box was objecting to. =C2=A0And i= t would also be helpful to see a data packet or two just to see normal data= flow before whatever is going wrong. There is apparently no active traffic on these connections; netstat shows them as in FIN_WAIT_2 state.