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 <wireshark@xxxxxxx> 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