Re: bin/49868: tftpd(8) doesn't play well with clients that return acknowledgements to the broadcast address

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

The following reply was made to PR bin/49868; it has been noted by GNATS.

From: Brian Buhrow <buhrow%nfbcal.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Cc: buhrow%nfbcal.org@localhost
Subject: Re: bin/49868: tftpd(8) doesn't play well with clients that return acknowledgements to the broadcast address
Date: Thu, 30 Apr 2015 18:37:01 -0700

 On May 1, 12:45am, Robert Elz wrote:
 } Subject: Re: bin/49868: tftpd(8) doesn't play well with clients that retur
 } The following reply was made to PR bin/49868; it has been noted by GNATS.
 } 
 } From: Robert Elz <kre%munnari.OZ.AU@localhost>
 } To: gnats-bugs%NetBSD.org@localhost
 } Cc: 
 } Subject: Re: bin/49868: tftpd(8) doesn't play well with clients that return acknowledgements to the broadcast address
 } 
 }  The one issue I see with this change is that switching from a connect/send
 }  implementation to sendto (which happens in the patch independently of the new
 }  switch) means that netstat won't identify the clients any more.   It would be
 }  kind of nice if that didn't happen unconditionally - tftp isn't really
 }  performance critical, so perhaps packet sending could be in a new function
 }  which tests the switch, and the sendto variant is used only when the new option
 }  is given ... and perhaps even better, even if the option is there, after
 }  receiving a packet that was sent to the unicast address (ie: not communicating
 }  with one of these broken clients) connect() and revert to the send()
 }  method?    (But perhaps all that complication only if !SMALL if tftpd gets
 }  included in boot images for some reason).
 }  
 }  kre
 
 	Well, I confess I didn't realize the netstat implication of the
 change.  How important is the output of netstat relative to tftp for folks?
 Implementing the connect/send versus sendto methods based on the new
 switch, is, as Robert points out, a fairly large patch.  The current patch
 is tested and is known to work.  If there's not a lot of strong feeling on
 this issue, I'm inclined to commit as is. 
 
 	As to Robert's second suggestion, I'm not sure it's a good idea since
 one can't tell if the client at the other end died or is just sending to
 the broadcast address.   Some of the timeouts on these tftp clients are
 such that I'm not sure you'd get things going if the tftp server was trying
 to decide which traffic it might or might not be receiving.  
 
 -thanks
 -Brian