Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Nov 1999 09:14:00 -0500
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc:        "Kenneth D. Merry" <ken@kdm.org>, jlemon@americantv.com (Jonathan Lemon), current@FreeBSD.ORG
Subject:   Re: TCP sockets stuck in the CLOSING state 
Message-ID:  <199911071414.JAA77246@whizzo.transsys.com>
In-Reply-To: Your message of "07 Nov 1999 13:41:48 %2B0100." <xzpogd61njn.fsf@flood.ping.uio.no> 
References:  <199911052219.PAA01743@panzer.kdm.org>  <xzpogd61njn.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help

> "Kenneth D. Merry" <ken@kdm.org> writes:
> > Jonathan Lemon wrote...
> > > In article <local.mail.freebsd-current/199911042000.NAA91632@panzer.kdm.org> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911071414.JAA77246>