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

[sthaug at nethelp.no]

> The VIVSO option is defined to contain an encapsulated option space,
> where the option code is a 32-bit integer equal to the vendor's
> enterprise-ID, and the length is a single octet.
> 
> It does not define any pad or end value.
> 
> What's happening in this tcpdump is it is giving an enterprise-ID
> of 0x0000113d (Broadcom), and a length value of 1, and an option
> contents value of 6, just that one byte.  Then the next option in
> the VIVSO buffer says it is enterprise-id 0x30303031, with a length
> option of 0x33, 51 octets.  But there are only 25 octets left in
> this 36-octet buffer (we consumed 6 for the previous option).
> 
> So we log an error.

Excellent, that makes the whole thing clearer.

> It's pretty clearly a garbage VIVSO option contents.  Perhaps our
> log message could be clearer.

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.

> The right thing to do here is to complain to the manufacturer who
> is sending these packets, citing RFC3925 section 4.

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

Steinar Haug, Nethelp consulting, sthaug at nethelp.no