A Windows 2012R2 server is sending out DHCP offer and DHCP ack without the End "FF"option. This only happens when a "long"custom option is included. Wireshark marks the the DHCP portion as malformed packet.
udp.length is 390 bytes.
If I remove the custom option the DHCP offer / ack contains the end option. If I put only a few bytes in the custom option, the DHCP offer / ack contains the end option.
The ip-phone has no issues with the DHCP offer / ack without the end option. Packets captured on both the DHCP server and on the wire, the server truly omitting the END option
Is wireshark correct in marking it as malformed ? Or is the MS windows dhcp at fault in not sending the End option ?
Has anyone observed this kind of behaviour.
asked 29 Nov '16, 03:58
edited 30 Nov '16, 02:43
Oh, that's interesting (and the reason why we always need to see the capture file, not a screenshot!! ): the end option is there.
Try loading the capture in Wireshark 1.10.x. There the packets show nothing malformed.
Now load it in Wireshark 2.2.x. There the packets show up as malformed.
So what's the difference? Vendor-specific Information dissection.
In version 1.10.x there is none for Enterprise: Mitel Corp. (1027)
In version 2.2.x there is. It sees a suboption in there with again a length. But this suboption length is the same value as the option length. It doesn't take into account the octets used for Tag and Length of the option. Therefore it's too large and the TVB runs out of data before the 100 octets of the suboption are parsed. Hence the malformed packet error.
answered 30 Nov '16, 06:09
edited 30 Nov '16, 10:41
The relevant RFC here is RFC 2131 which states, in section 4.1:
answered 29 Nov '16, 22:12