[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New class of receive error
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>
| 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
the configuration file, rtadvd adds the corresponding prefix to its
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
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
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.
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
Main Index |
Thread Index |