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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Brian Buhrow <buhrow%nfbcal.org@localhost>
Cc: gnats-bugs%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: Fri, 01 May 2015 18:07:26 +0700

     Date:        Thu, 30 Apr 2015 18:37:01 -0700
     From:        Brian Buhrow <buhrow%nfbcal.org@localhost>
     Message-ID:  <201505010137.t411b1YQ023322%lothlorien.nfbcal.org@localhost>
 
   | How important is the output of netstat relative to tftp for folks?
 
 I'll leave that for others to comment on.
 
   | Implementing the connect/send versus sendto methods based on the new
   | switch, is, as Robert points out, a fairly large patch.
 
 Not that large, surely, change send() to tftp_send() (or whatever), and put
 the necessary logic in a new function.
 
   | 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.
 
 Sorry, I don't see your point there?   At the relevant time, you're 
 communicating with a single client.  That client is either one of the
 broken ones, or it is not.  If it sends to your unicast address, rather
 than the broadcast address, it is not broken - and would be very unlikely,
 I'd think, to break itself in the middle of one session.   I'm not sure
 of the relevance of timeouts or missing packets to that - if you don't receive
 anything, you're not getting any info, and keep on with the possibility that
 the client, when it does send, will be a broken one.
 
 Doing this does mean that the code on receiving a packet (at least when the
 "allow for a broken client" flag remains set) must do the magic ioctl/sockioctl
 (or recvfrom or however it is done) to determine the address the client sent
 its packet to, which adds some extra mess (though there's no real reason to
 not do that for every packet, so conditional code is at least not required).
 
 Whether any of this complication is useful of course depends upon the outcome
 of your first question.
 
 kre