On Fri, Dec 27, 2002 at 11:08:29PM +0100, Michael Tuexen wrote:
> I'm thinking about a protocol with parameters having TLV structure.
> Consider a parameter for an IPv4 address. The parameter header is
> 4 bytes long, the IPv4 address 4 bytes long, so the protocol
> says that the parameter length MUST be 8 bytes long.
>
> Writing the dissector I thought it would be the 'correct way' to
> set the reported_length for the parameter TLV to 8, because that
> is what the protocol definition says.
Well, that's not what "reported length" was originally intended to mean
- it means "the length of the packet, as reported by the capture
mechanism" (as opposed to "the length of the packet data, as supplied by
the capture mechanism"), not "the length of the packet as specified by
the protocol", although I guess it could be used for that in contexts
where you're dealing with subfields of a packet rather than a packet.
> Then I write the code
> to display the 8 bytes. But what happens if someone sends a
> non-conform parameter with a length of 12 bytes?
>
> Of course I can go through all the parameters, see if there is
> a defined length and handle the stuff explicitly. But there are
> a lot of protocols using the TLV structure (SCTP, ASAP, M2UA, M3UA,
> SUA, M2PA, ...) that have the same problem. So I thing it
> is a good way to simply set the reported length.
Well, there is a call to set the reported length; however, that call
does not treat a reported length < the actual length as an error. It
could be changed to do that.
However, I don't see why
tvb_set_reported_length(tvb, 4);
would be any better than
tvb_check_length(tvb, 4);
with "tvb_check_length()" throwing some exception if the length of the
tvbuff is greater than the specified length.
