[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SACK, FIN -- openbsd(2001-03) to linux 2.4.14
Question deals with tcp, SACK, and FIN bit in resent packet:
"But I don't think the FIN bit should have been set in that resent packet."
[at end of message]
Equipment:
OpenBSD 2.8-current (DELL_DESKTOP) #1: Sun Mar 25 18:35:55 CST 2001
(Current from last year about this time -- I see no fixes in SACK.)
Linux kernel 2.4.14 (kernel.org, mips box, with a few 2.4.15 patches).
Procedure:
ftp put from openbsd to linux box. Tried 3 different ftpd's on linux box.
Finally at 10pm last night, I captured via ethereal the failure. (Sometimes
files sent are truncated on the linux box. Write to a log was put in ftpd,
showing the bytes read in the ftpd. Yes, a 0 was returned from the read(),
and I even tried looping back and trying read twice more.) With repeated
retries, I can get it to happen somewhat repeatedly (read that: 1 in 10?).
I apologize for long lines, but it is more appropriate for tcpdump output.
A fellow co-worker translated via tcpdump the failed transfer, and it follows:
> From swahl@brecis.COM Thu Apr 4 08:35 PST 2002
------------------------------------------------------------------------------
> If you're on a windowed system, you'll have to widen this out to see it clearly.
>
> Lucky for me, ethereal and tcpdump share the same save file format.
> I haven't used ethereal that much, and tcpdump does some things that
> ethereal doesn't seem to do (at least by default). The most important
> of which is subtract off the initial sequence number for a TCP
> conversation so you see it in (seq - orig.seq) form.
>
> I've narrowed it down to only the packets that are involved in the
> faulted conversation.
>
> First three packets: syn/syn-ack/ack three way handshaking as normal:
>
> 21:58:13.961815 192.168.1.100.47971 > 192.168.1.2.1048: S 978541877:978541877(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 57297 0>
> 21:58:13.962205 192.168.1.2.1048 > 192.168.1.100.47971: S 856178692:856178692(0) ack 978541878 win 5792 <mss 1460,sackOK,timestamp 31404 57297,nop,wscale 0> (DF)
> 21:58:13.962230 192.168.1.100.47971 > 192.168.1.2.1048: . ack 1 win 17376 <nop,nop,timestamp 57297 31404>
>
> Bytes 1 - 1024 sent by sender:
>
> 21:58:13.965560 192.168.1.100.47971 > 192.168.1.2.1048: P 1:1025(1024) ack 1 win 17376 <nop,nop,timestamp 57297 31404> [tos 0x8]
>
> Bytes 1025 - 2472 sent by sender:
>
> 21:58:13.965708 192.168.1.100.47971 > 192.168.1.2.1048: . 1025:2473(1448) ack 1 win 17376 <nop,nop,timestamp 57297 31404> [tos 0x8]
>
> Bytes through 1024 ack'd by reciever:
>
> 21:58:13.966117 192.168.1.2.1048 > 192.168.1.100.47971: . ack 1025 win 7168 <nop,nop,timestamp 31405 57297> (DF)
>
> Bytes 2473 - 3920 sent by sender:
>
> 21:58:13.966140 192.168.1.100.47971 > 192.168.1.2.1048: . 2473:3921(1448) ack 1 win 17376 <nop,nop,timestamp 57297 31405> [tos 0x8]
>
> Bytes 3921 - 5368 sent by sender:
>
> 21:58:13.966151 192.168.1.100.47971 > 192.168.1.2.1048: . 3921:5369(1448) ack 1 win 17376 <nop,nop,timestamp 57297 31405> [tos 0x8]
>
> Bytes through 2472 ack'd by receiver:
>
> 21:58:13.966302 192.168.1.2.1048 > 192.168.1.100.47971: . ack 2473 win 10136 <nop,nop,timestamp 31405 57297> (DF)
>
> Bytes 5369 - 6816 sent:
>
> 21:58:13.966319 192.168.1.100.47971 > 192.168.1.2.1048: . 5369:6817(1448) ack 1 win 17376 <nop,nop,timestamp 57297 31405> [tos 0x8]
>
> Bytes 6817 - 6989 sent, plus FIN indicating end of transmission.
>
> (for those unfamiliar, SYN counts as sequence 0 of the
> transmission, and FIN counts as a byte at the end, so in this
> case, fin is byte 6990, ack value of 6991 says fin is rec'd).
>
> 21:58:13.966326 192.168.1.100.47971 > 192.168.1.2.1048: FP 6817:6989(172) ack 1 win 17376 <nop,nop,timestamp 57297 31405> [tos 0x8]
>
> Ack of bytes thru 2472, plus selective ack of 3921 - 5368:
> (so receiver must have lost 2473 - 3920, which is one packet
> above)
>
> 21:58:13.966963 192.168.1.2.1048 > 192.168.1.100.47971: . ack 2473 win 10136 <nop,nop,timestamp 31405 57297,nop,nop,sack sack 1 {3921:5369} > (DF)
>
> Ack of bytes thru 2472, plus selective ack of 3921 - 6816:
> (receiver still says it lost 2473 - 3920)
>
> 21:58:13.967142 192.168.1.2.1048 > 192.168.1.100.47971: . ack 2473 win 10136 <nop,nop,timestamp 31405 57297,nop,nop,sack sack 1 {3921:6817} > (DF)
>
> Ack of bytes thru 2472, plus selective ack of 3921 - 6989:
> (receiver still says it lost 2473 - 3920, does not acknowledge ack)
>
> 21:58:13.967274 192.168.1.2.1048 > 192.168.1.100.47971: . ack 2473 win 10136 <nop,nop,timestamp 31405 57297,nop,nop,sack sack 1 {3921:6990} > (DF)
>
> Resend of bytes 2473 - 3920, PLUS FIN bit. This is where we start to
> fall apart. Reciever takes FIN as byte 3921, sender thinks sequence
> number of FIN is 6990. (Liberal in what you recieve and conservative
> in what you send would dictate to me that you send the fin in a
> separate packet):
>
> 21:58:13.967290 192.168.1.100.47971 > 192.168.1.2.1048: F 2473:3921(1448) ack 1 win 17376 <nop,nop,timestamp 57297 31405> [tos 0x8]
>
> Reciever acks up to 3921 (including where it thinks the FIN bit is):
>
> 21:58:13.967985 192.168.1.2.1048 > 192.168.1.100.47971: . ack 3922 win 13032 <nop,nop,timestamp 31405 57297> (DF)
>
> Receiver sends a Fin, its part of ending the conversation:
>
> 21:58:13.974824 192.168.1.2.1048 > 192.168.1.100.47971: F 1:1(0) ack 3922 win 13032 <nop,nop,timestamp 31406 57297> (DF)
>
> Twice:
>
> 21:58:14.184119 192.168.1.2.1048 > 192.168.1.100.47971: F 1:1(0) ack 3922 win 13032 <nop,nop,timestamp 31427 57297> (DF)
>
> Sender is confused by the ack number (I need to send that far back in
> the stream?), sends bytes 3922 - 5369, without the FIN:
>
> 21:58:14.479566 192.168.1.100.47971 > 192.168.1.2.1048: . 3922:5370(1448) ack 1 win 17376 <nop,nop,timestamp 57298 31427> [tos 0x8]
>
> Reciever again tries to end the conversation:
>
> 21:58:14.604064 192.168.1.2.1048 > 192.168.1.100.47971: F 1:1(0) ack 3922 win 13032 <nop,nop,timestamp 31469 57298> (DF)
>
> Sender Acks the FIN.
>
> 21:58:14.604097 192.168.1.100.47971 > 192.168.1.2.1048: . ack 2 win 17376 <nop,nop,timestamp 57299 31469> [tos 0x8]
>
> But sender is still trying to send the rest of the data:
>
> 21:58:16.479647 192.168.1.100.47971 > 192.168.1.2.1048: . 3922:5370(1448) ack 2 win 17376 <nop,nop,timestamp 57302 31469> [tos 0x8]
>
> Reciever doesn't believe he should be receiving more data, he already
> acked a FIN:
>
> 21:58:16.480303 192.168.1.2.1048 > 192.168.1.100.47971: R 856178694:856178694(0) win 0 (DF) [tos 0x8]
>
>
> I'll have to do some RFC reading, as I never implemented the selective
> ACK's. They came about later. But I don't think the FIN bit should
> have been set in that resent packet.
>
> --> Steve