In Windows 7 I am setting a custom DHCP client class id (DHCP Option 77)
and in Wireshark I am capturing the DHCP handshake. The custom class id is present in the DHCP request, but wireshark has the Option 77 info highlighed with the error "malformed option".
Any ideas on this? Is it a bug, either in Wireshark or Windows?
Edit: using Version 1.12.0 (v1.12.0-0-g4fab41a from master-1.12)
I've discovered that the first byte of the option string is being read as the value length. In my case, "1" is interpreted as length 49, whereas it is actually the first char of my user class. Cloudshark: https://www.cloudshark.org/captures/ecc7ed937a6a
Here's a hacky edit where I'm tacking on a placeholder byte at the beginning of the class to be read as the length. E.g., my class should start "101-...", so I made it "1101-..." and padded it to 49 chars, which wireshark parses happily. Cloudshark: https://www.cloudshark.org/captures/cf0b15f11b83
asked 08 Aug '14, 12:35
edited 08 Aug '14, 14:28
Looks like a bug in the DHCP client to me. RFC 3004 states that each instance of user class data should have a 1 octet prefix of the length.
answered 08 Aug '14, 16:25
This does not seem to be a bug in the DHCP client, but rather a conflicting specification. Microsoft defines DHCPv4 option code 77 as follows (see 22.214.171.124 User Class Option Sent by DHCPv4 Client to DHCPv4 Server):
They recognize that it is deviating, see 2.2.6 DHCPv4 Option Code 77 (0x4D) - User Class Option:
Upon further inspection, it appears that implementations vary in the implementation:
Wireshark should probably be modified to recognize this not apparently not so uncommon case. (I encountered while monitoring DHCP traffic from the iPXE implementation shipped with QEMU 2.6.0).
answered 20 Aug '16, 15:38
isc dhcp client also do the same thing...(it will not add the total length ) before adding all the instances.
servers may not send the response because of this bug....
answered 25 Nov '14, 08:36
edited 25 Nov '14, 08:39