parse_option_buffer: option <unknown> (808464740:50) larger than buffer.

[David W. Hankins]

On Wed, Sep 17, 2008 at 09:15:05PM +0200, sthaug at nethelp.no wrote:
> If it's reasonably easy to log the MAC address or some other value we
> can use to identify the DHCP client, it would make our lives easier.
> Currently we have to correlate the dhcpd log messages with sniffer
> logs to identify the client.

That's true.  But no, it's pretty hard at that layer in software.
It only knows the buffer it was handed.

Really a log message in general is pretty helpless here.

It seems like it would be nicer to keep a buffer of "the last 25
packets with errors I saw", and some markup of what (and where)
it all went wrong.

Sort of the packet-processing equivalent of a gdb backtrace, or
the way the config parser logs warnings with line numbers and
context.

We could log some kind of information upon inserting to the queue,
so you know to go query it, rather than at the point the error
ocurred.  That would be at the top of processing rather than down
in the individual guts, so we could log client identifying info
there, message (if we got a valid one), relay or interface etc.

This and statistics are two things I should probably spend more
time thinking about.

> Agreed. But the likelihood of this happening is low, since customers
> buy their own DSL modems and WLAN routers.

It'd be really nice if everyone had an 'rfc-compliance@' at every
domain, like the abuse@ convention.  It can be a real pain to finally
find _someone_ to talk to who doesn't think you're a nut or some
creepy stalker.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins