On 07/08/2018 17:54, Andreas Gustafsson wrote:
On April 28, Roy Marples wrote:
On 27/04/2018 23:58, Robert Elz wrote:
We really need to turn off the error on recv() by default - and allow it
to be turned on by applications that actually want to deal with this.
Why should we special case reporting this error instead of others?
While NetBSD might be the first BSD to report ENOBUFS for recv(), it's
certainly not the first OS to do so.
I suspect NetBSD may be the first and only to return ENOBUFS for recv()
on ordinary UDP sockets, and that this has broken BIND, which is
treating ENOBUFS on UDP recv() as an unrecoverable error; see PR misc/53421
and http://mail-index.netbsd.org/tech-kern/2018/08/07/msg023815.html .
There is not enough information to say for sure.
This could be a non validated address, the behaviour would be as described.
If there actually existed another OS that exhibited this behavior,
then surely BIND would have exposed the issue long ago, and either
BIND or the OS in case would have been fixed.
Please restore the old behavior, at least for UDP sockets.
Try reading the bind sources:
I'll quote it here for good measure:
/* Should never get this one but it was seen. */
That part of the code was imported into NetBSD over 10 years ago, which
massively pre-dates my recent change to recv() on NetBSD.
Similar code in unbound (which I use extensively without issue) also
tests for ENOBUFS, which again pre-dates my recv() change but instead
works around the error instead of just calling it a day.
I've not found where bind opens the socket yet, but hopefully as it hard
aborts specifically for ENOBUFS on recv it will ensure a large enough
buffer is allocated for recv - unbound sets the maximum possible for