Kevin A. Noll wrote:
The dissector in question is packet-wlccp.c.
Regarding heuristic or not, I still don't fully understand what the
difference is. I don't think this one is heuristic, and this should be the
top layer protocol, so I wouldn't need to hand it off to another recipient.
"Heuristic" is a general term; one use of it is to describe the
mechanism for heuristic dissectors, but it has other uses - even within
Wireshark.
In this case, you said:
I'm trying to decode a packet that has TLVs at the end of it. One of
the possible TLVs is a "NULL" TLV, which is simply one or more bytes
with the zero value. However, if it's any other kind of TLV, it is
likely to start with a zero and then be followed by another value that
indicates the actual type.
Presumably, the code in Cisco's equipment doesn't go past the end of the
packet to figure out what type of TLV a given TLV is, so there must be a
way to determine for certain whether a TLV is a null TLV or not, not
just whether it's "likely" to be one. A check that only determines
whether something is "likely" to be a null TLV would be a heuristic
check (in the sense that it's "experimental", i.e. poking at the TLV's
contents to try to determine what type of TLV it is).
Is this for version 0x00 or version 0xC1? If it's version 0xC1 - the
only version for which the dissector currently has any TLV code - the
patent application speaks of a TLV as having a minimum of 4 bytes. Does
the null TLV have a particular type ID value? Perhaps it has a type
code of 0 (container flag off, encrypted flag off, reserved bits 0 as
they should be, group ID 0, request flag off, type ID 0), which means it
presumably has a length value of 4 (as the length field includes the
length of the type and length fields).
Or, if the NULL TLVs only appear at the end of the packet, perhaps
they're not TLVs - perhaps they're padding?
