[Chris Hall <wireshark@xxxxxxx>]

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

Attachment: wireshark.pcapng
Description: Binary data