http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2194
Jim Young <jyoung@xxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jyoung@xxxxxxx
--- Comment #4 from Jim Young <jyoung@xxxxxxx> 2008-01-21 04:03:53 GMT ---
Hello Alex,
It looks like the dhcp packets you provided are not correctly constructing the
Overload option (t=52) field. If you expand the tree and look at the packet
details, the Option 52 item in your trace file you you'll see this:
> Option: (t=52,l=0) Option Overload length isn't >= 1
The description text "Option Overload length isn't >= 1" indicates that
Wireshark believes there is a problem this option. ;-)
The DHCP Options and BOOTP Vendor Extensions spec (RFC 2132) says:
> 9.3. Option Overload
>
> This option is used to indicate that the DHCP 'sname' or 'file'
> fields are being overloaded by using them to carry DHCP options. A
> DHCP server inserts this option if the returned parameters will
> exceed the usual space allotted for options.
>
> If this option is present, the client interprets the specified
> additional fields after it concludes interpretation of the standard
> option fields.
>
> The code for this option is 52, and its length is 1. Legal values
> for this option are:
>
> Value Meaning
> ----- --------
> 1 the 'file' field is used to hold options
> 2 the 'sname' field is used to hold options
> 3 both fields are used to hold options
>
> Code Len Value
> +-----+-----+-----+
> | 52 | 1 |1/2/3|
> +-----+-----+-----+
I would conclude that you have malformed DCHP packets and that Wireshark is
properly dissecting the DHCP packets.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.