Hi Chris, You could try the development version, which already has a solution to this issue implemented.
Thanks, Jaap > On 5 Mar 2025, at 16:09, Chris Hall <wiresh...@gmch.uk> wrote: > > > I enclose a short .pcapng which includes one DHCP Discover and one DHCP > Request message. Both contain the same malformed Option 124 > (Vendor-Identifying Vendor Class). The dissector spots this and reports it. > > So far, so good. > > Option 124 comprises a number of variable length 'vendor-class-data' fields, > each comprising a number of variable length 'opaque-data' items. In this > case one of the required 'data-len' octets *inside* the option has been > omitted. So the body of the option appears to exceed the overall option > length. > > The dissector gives up as soon as it sees the error. It does not show any of > the following options. As it happens, there are four of those in the DHCP > DISCOVER message. > > I suggest the dissector is giving up too early. Or, conversely, the > dissector is considering the contents of each option too early. > > Obviously, a DHCP server can simply step past options it does not care about > (or does not understand), without considering the contents of any option. In > this case, a DHCP Server that does not handle Option 124 will find the > messages perfectly well formed. > > I suggest the dissector should first step through the options and check that > they end with the expected 0xFF 'End Option', and: > > * if the expected 0xFF is not found, then something is badly wrong > and the dissector may have difficulty making sense of it all. > > * but where the expected 0xFF *is* found, it would be reasonable > for the dissector to then show all the options, and assume that > any errors found within a given option, are internal to that > option. > > Anyway: the way the dissector currently handles this particular kind of > problem: > > a) hides information about the well formed options which follow > the broken one. > > b) overstates the significance of the internal error in the > malformed option. > > Chris _______________________________________________ Wireshark-dev mailing list -- wireshark-dev@wireshark.org To unsubscribe send an email to wireshark-dev-le...@wireshark.org
