Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!lll-crg!styx!SCRC-QUABBIN.ARPA!DCP From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Data after a FIN Message-ID: <860615162744.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 15-Jun-86 16:27:00 EDT Article-I.D.: FIREBIRD.860615162744.2.DCP Posted: Sun Jun 15 16:27:00 1986 Date-Received: Wed, 18-Jun-86 03:12:28 EDT References: <860414094641.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Sender: daemon@styx.UUCP Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa Date: Mon, 14 Apr 86 09:46 EST From: David C. Plummer 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.