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

David W. Hankins David_Hankins at isc.org
Wed Sep 17 21:01:45 UTC 2008


On Wed, Sep 17, 2008 at 04:46:38PM -0400, Reissom Beshir wrote:
> 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.

Oh, that's curious.  I'm not sure what our software does in that case.
It really shouldn't be looking beyond the 4 bytes of the option 124
contents; we layer the function calls so the processing of each
option space doesn't try to fetch values from alien parts of the
packet.

But that's something we can try to reproduce pretty easily.

Clearly a packet format problem tho.

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