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>]

    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