Date: Fri, 13 May 2011 23:39:49 -0400 From: Ivan Voras <ivoras@freebsd.org> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-net@freebsd.org Subject: Re: Spurious ACKs, ICMP unreachable? Message-ID: <BANLkTikn_3EkHsqdkERpaqLxrGmCJXysGQ@mail.gmail.com> In-Reply-To: <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com> References: <iqk323$f8e$1@dough.gmane.org> <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 May 2011 17:38, Chuck Swiger <cswiger@mac.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikn_3EkHsqdkERpaqLxrGmCJXysGQ>