NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On May 1, 12:45am, 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
} 
}  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).
}  
}  kre

	Well, I confess I didn't realize the netstat implication of the
change.  How important is the output of netstat relative to tftp for folks?
Implementing the connect/send versus sendto methods based on the new
switch, is, as Robert points out, a fairly large patch.  The current patch
is tested and is known to work.  If there's not a lot of strong feeling on
this issue, I'm inclined to commit as is. 

	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.   Some of the timeouts on these tftp clients are
such that I'm not sure you'd get things going if the tftp server was trying
to decide which traffic it might or might not be receiving.  

-thanks
-Brian




Home | Main Index | Thread Index | Old Index