On 27/04/2018 07:05, Robert Elz wrote:
Date: Fri, 27 Apr 2018 05:18:16 +0100
From: Roy Marples <roy%marples.name@localhost>
Message-ID: <58598dae-238e-44a5-e74f-bbb2fdd7bdfc%marples.name@localhost>
| No-one has yet weighed in on how this should be resolved.
Go back to silently discarding the error (at least, by default).
Datagram type services (which is what the routing socket,
and others like it, are) generally are just "best effort" with
no error reporting at all. The higher level protocol needs to
cope.
However, some kind of sockioctl() to enable error reporting
would be OK, for applications that actually need to know
(but they still need to cope with data lost for other reasons.)
What might be interesting to discover however, is just why
there are so many routing socket errors with the buffer space
exhausted - particularly on a huge system like Paul's. I would
have expected this to be rare assuming everything else is
working correctly.
My understanding (and I've not looked, so could be wrong) is that the routing socket gets a 2k buffer by default regardless of how big your memory is.
Since NetBSD-5, I've modified the kernel to announce IPv6 address state changes, introduced IPv4 address state changes which are also announced AND added a layer of compat to the more generic RTM messages so that interface address changes can report back PID and flags. In other words, while a 2k buffer might have been fine for NetBSD-4 (and we'll never really know because overflow errors were silently dropped) it might not be fine for a router with many addresses that all become active with the internet decides to work. This is an important part because of all the NetBSD machines I have, the routing socket only overflows on my ERLITE router. The other physical servers, laptops and VMs I have do not.
Roy