Data after a FIN


David C. Plummer (DCP@QUABBIN.SCRC.Symbolics.COM)
Sun, 15 Jun 86 16:27 EDT


    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.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:34 GMT