ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] bad handling of DHCP option 90?

From: Stefan Puiu <stefan.puiu@xxxxxxxxx>
Date: Mon, 23 Apr 2007 21:49:50 +0000 (UTC)
Stefan Puiu <stefan.puiu@...> writes:

> 
> Hi all,
> 
> I captured some DHCP traffic using DHCP AUTH (option 90  - see
> RFC3118) using tcpdump on a Linux device and was then trying to view
> it from wireshark (0.99.4) on Windows. The problem is I'm getting some
> warnings on the option length, and I think they are wrong.

OK, I've decided to dive a bit into the code and see what's wrong. I seem to
have found the offending code in epan/dissectors/proto-bootp.c. 

It seems that there's a general check on option 90 so that the length field is
>= 11, which seems right according to RFC3118. Then, wireshark expects the
option length to be >= 31 if HMAC-MD5 is used - trouble is, that is valid for
packets of any other type besides DHCPDISCOVER. Here'an attempt at a patch -
since I'm using cygwin on Windows, I can't verify it: 

--- packet-bootp.c.orig	2007-02-02 00:00:56.000000000 +0200
+++ packet-bootp.c	2007-04-24 00:42:44.267830400 +0300
@@ -1172,11 +1172,20 @@
 			switch (algorithm) {
 
 			case AUTHEN_DELAYED_ALGO_HMAC_MD5:
-				if (optlen < 31) {
+				if (!strcmp(*dhcp_type_p, "Discover")) {
+					if (optlen < 11) {
+						proto_item_append_text(vti,
+											   " length isn't >= 11");
+						break;
+					}
+				}
+				else if (optlen < 31) {
 					proto_item_append_text(vti,
 						" length isn't >= 31");
 					break;
 				}
+				
+				
 				proto_tree_add_text(v_tree, tvb, optoff, 4,
 					"Secret ID: 0x%08x",
 					tvb_get_ntohl(tvb, optoff));

Basically, it uses 11 as the minimum size if the DHCP message type is
DHCPDISCOVER, and 31 otherwise. 

Stefan.