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

David W. Hankins David_Hankins at isc.org
Wed Sep 17 18:42:45 UTC 2008


On Wed, Sep 17, 2008 at 07:27:09PM +0200, sthaug at nethelp.no wrote:
> The relevant portion of the packet is the Option 125 info starting at
> tcpdump offset 0x011f: 7d 2400 0011 3d01 0630 3030 3133 ... We have
> here an option 125 (0x7d) field, length 36 (0x24) which starts with
> two zero bytes. Zero is the code for "pad" in the option space, and
> I believe dhcpd gets out of step here and tries to interpret part of
> the 36 byte string within the option 125 field as a suboption - note
> the "30 3030 31" is the same as is logged by dhcpd as 808464740.

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.

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

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

-- 
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


More information about the dhcp-users mailing list