Spurious ACKs, ICMP unreachable?

[Julian Elischer]

On 5/13/11 11:39 PM, Ivan Voras wrote:
> On 13 May 2011 17:38, Chuck Swiger<cswiger at 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 again.  The next packet on the same connection then ACK's something outside of the window with a 64K window size.  That's wrong; the other side probably sends an RST and the ICMP error.  If 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 help identify which connection the Windows box was objecting to.  And it would also be helpful to see a data packet or two just to see normal data flow before whatever is going wrong.
are you sure the acks are not keepalives generated by ipfw in the middle?

> There is apparently no active traffic on these connections; netstat
> shows them as in FIN_WAIT_2 state.
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>