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: Brian Buhrow <buhrow%nfbcal.org@localhost>, <Paul_Koning%dell.com@localhost>, 
	<gnats-bugs%NetBSD.org@localhost>
Cc: <gnats-admin%NetBSD.org@localhost>, <netbsd-bugs%NetBSD.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 17:00:12 -0400

 On Apr 30,  1:37pm, buhrow%nfbcal.org@localhost (Brian Buhrow) wrote:
 -- Subject: Re: bin/49868: tftpd(8) doesn't play well with clients that retur
 
 | 	Hello.  I think Christos' suggestion of turning on this functionality
 | with a  command line option and documenting that option is a good idea.  While
 | I don't think doing things just because Linux does them is a good reason,
 | I'll note that Linux's in.tftpd has the -a option which can be used to
 | implement this same functionality.  I think we should implement this
 | functionality because our users are pretty network savvy, they often work
 | with older broken equipment where they are likely to encounter this bug and
 | because having it will make it very convenient for our users to  work
 | around issues like this.  Before I figured out what was going on and how to
 | fix it, I was considering installing Linux or firing up my Windows
 | machine to deal with this piece of hardware.  Finally, given the fact that
 | this change only permits the reception of broadcast traffic on an ephemeral
 | port, not the main tftp port, it's unclear to me how much abuse potential
 | this change really introduces.  For most users, this addition will mostly
 | go unused.But, for those that need it, they'll be glad to have it in a
 | pinch!  I think that makes it worth doing.
 
 I agree, but I am wondering if one can fake a packet coming coming from a
 broadcast address and cause tftpd send datagrams to the broadcast address
 too. If that's the case, then a warning should be added to the man page
 next to the option documentation. I have not really examined the code to
 see if that's possible though (inetd and tftpd). Otherwise I think it is
 fine to commit this.
 
 christos