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

Reissom Beshir Reissom_Beshir at Mitel.com
Wed Sep 17 20:46:38 UTC 2008


David_Hankins at isc.org wrote:

>> I raised a bug report ISC-Bugs #18241.
>> I do not know what the status of the bug is.
>
> In that report, you indicated a length value of 0x10000 (65536).
>
> It should not be physically possible for that to ocurr, my only
> guess would be some compilation problem (try disabling optimization)
> or other wonky system error.

In my case the client sends option 124 in the server does reply with option 
125.
When the client sends the discover or request the server logs 
parse_option_buffer followed by the clients msg DHCPDISCOVER or DHCPREQUEST.

  parse_option_buffer: option <unknown> (1027:65536) larger than buffer.
  DHCPDISCOVER from 08:00:0f:00:aa:55 via eth0
  DHCPOFFER on 192.168.1.65 to 08:00:0f:00:aa:55 via eth0

Here's what the client sends in option 124, there's a 1-byte padding after 
that and ends with the end-option.

Option: (t=124,l=4) V-I Vendor Class
    7c 04 00000403
Padding    00
End Option FF

I looked at the RFC and it does indicate there is a data-len after the 
enterprise-number followed by vendor-class-data.  Now the client is only 
sending enterprise-number hence the total option length of 4 bytes.  I 
assume the server is interpreting the padding and end-option as part of the 
option 124 data.  If that is the case it should have detected the data-len 
of zero for the enterprise-number.

Thanks,
Reissom



More information about the dhcp-users mailing list