Re: New class of receive error

[Roy Marples <roy%marples.name@localhost>]

On 13/05/2018 16:59, Robert Elz wrote:
>      Date:        Sun, 13 May 2018 15:39:07 +0100
>      From:        Roy Marples <roy%marples.name@localhost>
>      Message-ID:  <88e323a6-c0ac-b870-ab38-7a34bde6ac2b%marples.name@localhost>
>
>    |  Comments that have existed in our code as far back as I've
>    | checked seem to agree with stuff like this:
>    | /* XXX notify userland of overflow */
>
> Where exactly is that string in the NetBSD kernel, I have looked and
> cannot find anything that even comes close.

Sorry, the exact text is this:
/* should notify about lost packet */

It appeared in quite a few places.

>    | Here's a list from a trivial
>    | search and basic examination:
>    | 	rarpd, racoon, ifwatchd, route (monitor), rtadvd
>
> That's all routing socket.   I don't even need to read the code
> to know that rtadvd doesn't care

But it does care. Here is some text from the fine man page.

    rtadvd also watches the routing table.  If an interface direct route is
     added on an advertising interface and no static prefixes are 
specified by
     the configuration file, rtadvd adds the corresponding prefix to its
     advertising list.

I didn't add that, predates my involvement with NetBSD.

 - but aside from that, those
> might potentially benefit.  The routing socket really is special.
> But they can only benefit of their code is changed, and if their
> code changes to gain that benefit, they could easily have a
> "turn on" sockioctl() added at the same time.   Until then all
> you have done is given them yet another error they can receive
> and have no idea what to do with.

And how is this a bad thing?
The outcome of this is that we now know syslogd receive buffers can 
overflow. This isn't noted anywhere in the man page and neither is there 
a configuration option to increase it anywhere I can see.

How do I, as a user, increase the buffers? More importantly, how do I 
increase them?
But most worringly for me, is that we as a group don't care about this 
and are in favour of just concealing the error from the user.

>    | I, for one, would be interested in knowing that the logging mechanism is
>    | failing.
>
> When it is syslog() that would be better performed at the sender.

Again, why is syslog special here? It's no more special than route(4). 
Lossing stuff is bad, concealing this fact is even worse.

While I agree solving at the sender would be ideal, that can't be done 
without adding non standard interfaces as all the returns are void.

> Aside from that, knowing (just for general information, rather than
> for any attempt to recover in a particular case) this is the kind of
> info that netstat -m should provide.   That could provide info that
> something is busier than the system is designed to handle, and
> bigger buffers might be useful (on a particular system).
>
>    | We don't know the importance of the message that would
>    | otherwise have been silently discarded. But at least we now know, so we
>    | can do something about it.
>
> Do what?

Empower the receiver into resolving it.

Take this error from my NetBSD powered router:
cnmac2: reception error, packet dropped (error code = 13)

What am I expected to do about that? As a user, I have exactly the same 
resources to address that as syslogd users currently do - zero.
So are suggesting we remove that error as well? Where do we draw the 
line here, or is syslog somehow special?

>    | > If you want complete routing information use synchronous queries
>    | > and use routing socket messages only as an optimization.
>    |
>    | I believe that's what I've done?
>
> Yes, I agree, no-one is doubting the code in dhcpcd - just that you have
> also inflicted this on every other application in the system, without fixing
> them to handle it (all that has happened is an increase in the buffer
> sizes so that it is less likely to happen - ie: an attempt to hide the issue
> so no-one notices.)

No, hiding the issue would be back to the old behaviour.
My attempt at resizing the default buffers just makes it less likely to 
happen.

Roy