Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!oberon!cit-vax!ucla-cs!zen!ucbvax!LANL.GOV!cpw%sneezy
From: cpw%sneezy@LANL.GOV (C. Philip Wood)
Newsgroups: comp.protocols.tcp-ip
Subject: Help with broken TCP
Message-ID: <8709011500.AA21222@sneezy.lanl.gov>
Date: Tue, 1-Sep-87 11:00:16 EDT
Article-I.D.: sneezy.8709011500.AA21222
Posted: Tue Sep  1 11:00:16 1987
Date-Received: Sat, 5-Sep-87 04:10:54 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 31

What follows is a TCP scenario observed on our local ethernet.  The ftp
application (A) has just pushed out the last data block to (B) and is
closing the connection.  The first FIN from (A) is lost.  An ACK from (B)
for the last data block arrives. Then there begins a conversation of FIN(A)
then ACK(B) with longer and longer time intervals between each set of
FIN(A)/ACK(B) as if the ACK is being dropped and a retransmit timer is
backing off, firing and a FIN being sent.  Notice that the sequence number
set in the retransmitted FIN packets is one less than that set in the lost
FIN packet.  Are both peers broken or just the sender of the FINs?

This is a tcpdump.  I added an * to indicate the lost packet.  (In case
your curious, the packet is lost because of an inability to handle back
to back packets on the part of B)

15:31:36.86  A > B: S -1063845887:-1063845887(0) win 4096 <mss 1024>
15:31:36.86  B > A: S 253698321:253698321(0) ack -1063845886 win 384 <mss 1024>
15:31:36.86  A > B: . ack 1 win 4096
15:31:37.12  A > B: P 1:146(145) ack 1 win 4096
15:31:37.12  A >* B: F 146:146(0) ack 1 win 4096
15:31:37.38  B > A: . ack 146 win 384
15:31:39.12  A > B: F 145:145(0) ack 1 win 4096
15:31:39.14  B > A: . ack 146 win 384
15:31:41.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
15:31:41.14  B > A: . ack 146 win 384
15:31:45.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
15:31:45.14  B > A: . ack 146 win 384
15:31:53.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
 
and so on...

Phil Wood  (cpw@lanl.gov)