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

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

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