Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Check for end of packet?

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 09 May 2007 13:02:47 -0700
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?