Well, you're right on the last point. The NULL TLVs appear at the end of the
packet as padding.
However, if you read the patent closely (for version 0xC1), you'll note that
the NULL TLV has no type or length value. So your description of "poking at
the packet" is pretty much what I want to do.
I know that there are or are not going to be TLVs based on the TLV flag
being set. After that I need to determine if there are more than just NULL
TLVs. So far, I've only seen NULL TLVs that are one byte long, but other
TLVs are identifed by having a group and a type number in the first two
bytes. The problem is that there are TLVs that are group=0x0, so I have to
potentially "poke" beyond the length of the packet to find out if there's a
real type value there.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
Kevin.Noll@xxxxxxxxxxxxx
+1-717-796-1936
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Wednesday, May 09, 2007 4:03 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Check for end of packet?
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?
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev