Bug 13401

Summary: tftp will ack duplicate packets with large delays
Product: Base System Reporter: David G Andersen <danderse>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 3.2-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description David G Andersen 1999-08-27 00:10:01 UTC 
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.

Fix: Instead of ACK'ing clearly duplicate packets, only re-ACK if we've
actually flushed packets out of the stream.
	
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.
Comment 1 iedowse freebsd_committer freebsd_triage 2002-01-21 20:46:34 UTC 
State Changed
From-To: open->feedback


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?
Comment 2 iedowse freebsd_committer freebsd_triage 2002-06-02 13:01:34 UTC 
State Changed
From-To: feedback->closed


Feedback timeout.