From danderse@cs.utah.edu Thu Aug 26 16:09:17 1999
Return-Path: <danderse@cs.utah.edu>
Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100])
	by hub.freebsd.org (Postfix) with ESMTP id D68EC1517A
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 26 Aug 1999 16:09:15 -0700 (PDT)
	(envelope-from danderse@cs.utah.edu)
Received: from torrey.cs.utah.edu (torrey.cs.utah.edu [155.99.212.91])
	by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id RAA10554
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 26 Aug 1999 17:07:36 -0600 (MDT)
Received: (from danderse@localhost)
	by torrey.cs.utah.edu (8.9.3/8.9.1) id RAA17439;
	Thu, 26 Aug 1999 17:07:34 -0600 (MDT)
	(envelope-from danderse@cs.utah.edu)
Message-Id: <199908262307.RAA17439@torrey.cs.utah.edu>
Date: Thu, 26 Aug 1999 17:07:34 -0600 (MDT)
From: David G Andersen <danderse@cs.utah.edu>
Reply-To: danderse@cs.utah.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: tftp client bad behavior with large packet delays or extra packets
X-Send-Pr-Version: 3.2

>Number:         13401
>Category:       bin
>Synopsis:       tftp will ack duplicate packets with large delays
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 26 16:10:01 PDT 1999
>Closed-Date:    Sun Jun 02 05:01:51 PDT 2002
>Last-Modified:  Sun Jun 02 05:01:51 PDT 2002
>Originator:     David G Andersen
>Release:        FreeBSD 3.2-STABLE i386
>Organization:
University of Utah
>Environment:

TFTP'ing between two machines with a potentially greater than 5 second
latency.  OR, a hostile environment in which an intruder can spoof a
tftp packet.

>Description:

When /usr/bin/tftp waits more than 5 seconds for a packet, it re-ACKs the 
previous packet.  If that previous packet was only delayed, then two
copies of the packet will arrive at the client.  The client will then send
an ACK for *both* packets, which causes the server to send two of the next
packet, and so on - doubling the data sent.  As this continues, eventually
you can get many many copies of each packet flowing.

>How-To-Repeat:

tftp with  > 5 second latency.  We encountered it testing some router code
which was misbehaving, but I have a packet latency inducer using divert
sockets with which I can reproduce this at will.  Contact me for the code.

>Fix:

Instead of ACK'ing clearly duplicate packets, only re-ACK if we've
actually flushed packets out of the stream.
	
Index: tftp.c
===================================================================
RCS file: /n/marker/usr/lsrc/FreeBSD/CVS/src/usr.bin/tftp/tftp.c,v
retrieving revision 1.4
diff -u -r1.4 tftp.c
--- tftp.c	1998/10/30 16:17:50	1.4
+++ tftp.c	1999/08/26 20:40:07
@@ -239,6 +239,7 @@
 			warn("sendto");
 			goto abort;
 		}
+no_send_ack:
 		write_behind(file, convert);
 		for ( ; ; ) {
 			alarm(rexmtval);
@@ -277,7 +278,14 @@
 					printf("discarded %d packets\n", j);
 				}
 				if (dp->th_block == (block-1)) {
-					goto send_ack;	/* resend ack */
+					if (j) {
+						goto send_ack; /* resend ack */
+					} else {
+						/* We didn't discard any
+						 * packets;  we got a duplicate
+						 */
+						goto no_send_ack;
+					}
 				}
 			}
 		}

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Mon Jan 21 12:46:34 PST 2002 
State-Changed-Why:  

The included patch isn't quite right. It doesn't reliably detect 
duplicates, and it causes protocol hangs if a packet gets lost. 
I think to fix this properly would require dynamically adjusting 
the timeout according to the observed round-trip time. 

Do you wish to try updating the patch, or shall I just close the 
problem report? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13401 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Sun Jun 2 05:01:34 PDT 2002 
State-Changed-Why:  

Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=13401 
>Unformatted:
