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  debugonthewire edited 30 Nov '16, 02:43 |
2 Answers:
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  Jaap ♦ edited 30 Nov '16, 10:41 Thanks very much, Interesting, I looked at the trace file in two Wireshark versions, even before posting on this forum, both show Malformed packets. The 2.2.2 version does indeed show the suboption value, but still marks it as malformed, without a end option. The versions I used are: Version 2.2.2 (v2.2.2-0-g775fb08) Version 1.12.13 (v1.12.13-0-g969649d from master-1.12) Which version Wireshark exactly did you use ? Anyway in the Hex plane a FF value is visible as the last byte, probably that is the End option, and the Wireshark dissector is at fault, or the Encapsulated string for option 125 is not correct. The encapsulated string for option 125 was created using the Mitel utility called DHCP option 125 Config helper". If you are correct about the suboption length, the Mitel utility is at fault. I am somewhat reassured that the issue seems to be with the encapsulated string or the dissector and not with the DHCP server. The IP-Phones understand the OFFER en ACK , but still worth looking into. (30 Nov '16, 08:14) debugonthewire 1 Oh, I checked again and found that it was indeed 1.10.14 where this problem was not seen. I've updated the answer accordingly. (30 Nov '16, 10:43) Jaap ♦ 1 Well, we're not out of the woods yet. Now RFC 3925 comes into play. Section 4 describes the exact make up of the Vendor-Identifying Vendor-Specific Information Option. It's a TLV inside a TLV inside TLV. (30 Nov '16, 13:57) Jaap ♦ 1 It seems to me that the suboption is malformed, as in, not consistent with the format stated at the end of RFC 3925 section 4. There it is stated that the enterprise option data has to be formatted as a TLV as well {subopt-code|subopt-len|sub-option-data}. This last TLV format isn't there. After the enterprise data length the option data starts straight away as string "id:ipphone.mitel.com;sw_tftp=192.168.20.2;call_srv=192.168.20.2;vlan=7;l2p=5v5s3;dscp=46v46s26;", where a subopt-code and subopt-len were expected first. So the fact that the tool generating this option and the phone receiving this option understand one another is fine for them, it's just not RFC 3925 compliant. On the other hand the Wireshark dissector should be strengthened against such erroneous TLV lengths. If put in a change to that effect https://code.wireshark.org/review/#/c/18999/ which does show this problem and shows the end option being present. (30 Nov '16, 14:44) Jaap ♦ Thanks I'll use your insights to open a try to open a support call with the Mitel company. (01 Dec '16, 05:51) debugonthewire |
The relevant RFC here is RFC 2131 which states, in section 4.1: answered 29 Nov '16, 22:12 Jaap ♦ Juniper's switches have an So we should probably stop parsing options if there are no bytes of option left, so that we don't run past the end of the packet, but we should, if we run out of option bytes rather than seeing an End option, mark the packet with an error-level expert info item indicating that the End option is missing. (30 Nov '16, 00:52) Guy Harris ♦♦ So, yes, Wireshark is correct in marking it as malformed, and the Windows DHCP is at fault in not sending the End option, as per the RFC. (30 Nov '16, 00:53) Guy Harris ♦♦ |
Can you share a capture in a publicly accessible spot, e.g. CloudShark?
As far as I can tell, neither RFC 1497 nor RFC 1533 nor RFC 1533 nor RFC 2132 seem to clearly indicate whether an End option is required at the end of the options, so, unless I've missed something, or unless there's some other specification that says it's required, it doesn't seem to be clear that it's required.
Tracefile uploaded on cloudshark https://www.cloudshark.org/captures/44fa27531e36
Thanks for the trace, see my latest answer.