> "Kenneth D. Merry" <[EMAIL PROTECTED]> writes:
> > Jonathan Lemon wrote...
> > > In article <local.mail.freebsd-current/[EMAIL PROTECTED]> you
>write:
> > > > Before I spend a lot of time hunting this down, I figured it might be worth
> > > > asking -- is there any particular reason why TCP sockets may be getting
> > > > stuck in the CLOSING state more often now?
> > > Not sure. But here's a tcpdump trace of a socket that ends up in the
> > > CLOSING state. (on the host ``cache'').
> > > [...]
> > > 1. the other end (folly) never acks the FIN. The packets at
> > > timestamp .492154 and .492160 do not cover the FIN in the
> > > sequence space. Yet the host `folly' closes the socket.
>
> This is weird, and probably deserves some investigation (at least if
> cache and folly are on the same LAN; otherwise there's a non-zero
> possibility of the ACK simply getting lost on the way)
>
> > > 2. the end that is stuck in CLOSING (cache) never retransmits
> > > the FIN. (The tcpdump extends for about 5 minutes after the
> > > last packet, with 0 packets lost).
>
> It's not supposed to (according to RFC793).
I think your interpretation of the TCP spec is in error. Since the FIN
occupies sequence space, it's the same as unacknowledged data and should
be retransmitted, just like any unacked data in the window would be.
Eventually, the TCP stack should timeout the connection with an ACK-timeout.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
