Guy,
see my comments below.
Best regards
Michael
On Friday, Dec 27, 2002, at 23:32 Europe/Berlin, Guy Harris wrote:
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.
OK, I see.
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.
tvb_check_length is a very good idea and it does not 'misuse' the
reported
length. I will play around with that solution. Thank you very much for
the hint.
