DCP@SCRC-QUABBIN.ARPA (David C. Plummer) (06/15/86)
Date: Mon, 14 Apr 86 09:46 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
We are noticing several hosts (e.g., UTAH-CS) that are sending a FIN,
then sending data, and finally a second FIN. Technically, The spec
says this should happen and the data should be discarded. What I want
to know is
- Who is doing this (I suspect 4.3BSD)? and
- Why? and
- Why doesn't anybody else know about it?
I was under the impression this list was a clearing-house for ideas, but
have absolutely no recollection of this being discussed.
This is still the case and here is some analysis. In and Out refer to
the packet direction from my local machine. My local machine is called
FIREBIRD and is at address 192.10.41.161 and will be notated F below (to
save space). UTAH-CS is at address 10.0.0.4 and will be notated U. The
number after the dash is the port number; 79 is the NAME protocol. I've
deleted the window-size field (they were always large enough for all
data) and the time-recorded field (it all happened within 4 seconds).
A,P,S and F stand for Ack, Push, Syn and Fin, respectively. Commentary
included (commentary is below the segment it is commenting on).
Out S F-1069->U-79 Seq=1915863851. Len=1
I ask for a connection.
In A S U-79->F-1069 Seq=1982144000. Ack=1915863852. Len=1
Utah responds with a SYN and ACKs my SYN.
Out A F-1069->U-79 Seq=1915863852. Ack=1982144001. Len=0
I ack Utah's SYN.
Out AP F-1069->U-79 Seq=1915863852. Ack=1982144001. Len=2
I send a newline (which is what the name protocol wants).
In A U-79->F-1069 Seq=1982144001. Ack=1915863854. Len=0
Utah ACKs my data.
In A U-79->F-1069 Seq=1982144001. Ack=1915863854. Len=512
Utah sends me 512 bytes of data.
In AP U-79->F-1069 Seq=1982144513. Ack=1915863854. Len=16
Utah sends me some more data.
In A F U-79->F-1069 Seq=1982144529. Ack=1915863854. Len=1
Utah sends me a FIN. All of this is in order.
Out A F-1069->U-79 Seq=1915863854. Ack=1982144530. Len=0
I acknowledge all of Utah's DATA and the FIN.
In A F U-79->F-1069 Seq=1982144530. Ack=1915863854. Len=1
>> Utah sends me another FIN beyond the one it already sent me!
Out A F F-1069->U-79 Seq=1915863854. Ack=1982144530. Len=1
After the user process gobbles the data, it closes the connection. This
acknowledges Utah's FIN (again) and asserts my own FIN.
In A U-79->F-1069 Seq=1982144001. Ack=1915863854. Len=512
Utah sends the first segment of data again(!) and ACKs my request, but
not my FIN. [This may be a packet sequencing manifestation and can
probably be ignored.]
Out A F-1069->U-79 Seq=1915863855. Ack=1982144530. Len=0
I again ACK Utah's FIN.
In A U-79->F-1069 Seq=1982144530. Ack=1915863855. Len=0
Utah finally ACKs my FIN and the connection is closed.
Why is Utah sending a double FIN? Is anybody out there listening? I
had no response from my query two months ago.DCP@QUABBIN.SCRC.Symbolics.COM.UUCP (06/19/86)
FYI, ============================== Date: Mon 16 Jun 86 18:50:25-MDT From: Jay Lepreau <Lepreau@UTAH-20.ARPA> Subject: Re: Data after a FIN To: DCP@SCRC-QUABBIN.ARPA In-Reply-To: <860615162744.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <12215395290.10.LEPREAU@UTAH-20.ARPA> Mike Karels says this has been fixed in the final 4.3 tape, which has been cut. I followed up on this before, I thought I told you about it. You can forward this on to the list if Mike doesn't respond himself in a little while. -------