DHCP Option 77 - malformed option

Question

In Windows 7 I am setting a custom DHCP client class id (DHCP Option 77)

ipconfig /setclassid "Local Area Connection" "SOME_CUSTOM_CLASS_ID"

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

Accepted Answer

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.

Answer 2

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 2.2.6.1 User Class Option Sent by DHCPv4 Client to DHCPv4 Server):

octet 0: Option Code (77, 0x4D)
octet 1: Option Length
octet 2...: User_Class_Data (variable)

They recognize that it is deviating, see 2.2.6 DHCPv4 Option Code 77 (0x4D) - User Class Option:

This section describes the message format of the User Class Option sent by DHCPv4 clients and DHCPv4 servers, and the values for this option that are predefined on DHCPv4 servers that implement this specification. The format of this option varies from the implementation described in [RFC3004] in that the User Class Data field format is changed. The use of this alternate format is indicated by the presence of a Vendor Class Identifier Option (section 2.2.3), which can occur anywhere in the same message.

Upon further inspection, it appears that implementations vary in the implementation:

iPXE implements the MS spec (it sends 77 04 "iPXE"). Related forum topic. See also documentation: "RFC 3004 defines the DHCP user class as a set of length-value tuples, but iPXE treats it as a string."
ISC DHCP: "RFC3004 [RFC3004] defines the User-Class option. Note carefully that ISC DHCP currently does not implement to this reference, but has (inexplicably) selected an incompatible format: a plain text string." (source)
dnsmasq implements uses heuristics to figure out whether to follow RFC 3004 or non-compliant behavior.
dhcpcd also uses the format 77 <N> <N octets>, source.

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

Answer 3

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