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

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	buhrow%nfbcal.org@localhost
Cc: 
Subject: Re: bin/49868: tftpd(8) doesn't play well with clients that return acknowledgements to the broadcast address
Date: Thu, 30 Apr 2015 21:58:14 -0400

 On May 1, 12:45am, kre%munnari.OZ.AU@localhost (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
 | Date: Fri, 01 May 2015 07:40:29 +0700
 | 
 |  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).
 
 I like that idea, and I was going to suggest that..
 
 christos