Ethereal-dev: Re: [Ethereal-dev] malformed packet: proto_tree_add_item() cores vs. exceptions?
> proto_tree_add_item() will try to read and parse the scalar from the TVB
itself
and store the FT_UINT32 into a guint32.
It will read as many bytes as specified in length into the guint32 and then
cann proto_tree_add_uint().
If length is >4 then obviously you can not fit the data into a guint32 and
ethereal aborts.
Yes, that is exactly my problem. Could it generate an exception in this
case (thus generating "[Malformed packet]")?
Is the integer scalar value actually of variable length and can it sometimes
be >4 bytes
in the integer?
The code snippet below seems hardcoded to always read it as a 24bit integer
and then
length would always be 3 ?
Ahh, yes, I should have mentioned that... Yes, a DLR (or an SLR)
parameter should always be 3 bytes long. But it's possible (not in real
life, but it does happen if "mtp3.standard" is set incorrectly for the
current capture) that the parameter could show up as an "optional" or
"variable length" parameter--in which case the indicated length of the
parameter (from the SCCP message itself) may be, well, anything that
fits in a guint8...
Another thing I tried is to do something like this:
#define DLR_LENGTH 3
if (length == DLR_LENGTH)
proto_tree_add_item(tree, hf_sccp_dlr, tvb, 0, length, FALSE);
else
{
proto_tree_add_text(tree, tvb, 0, length, "DLR of length %d?!?", length);
decode_error = TRUE; /* generate exception after decoding packet */
}
and then when I'm finished processing the message do this to force an
exception (malformed packet):
if (decode_error) /* we hit an error while dissecting the message */
proto_tree_add_text(tree, tvb, 0, tvb_length(tvb) + 2,
"Decoding error!");
but that's ugly and a lot more code...
Regards,
-Jeff
If the integers are up to 64bit in size, you may try to change it into
FT_UINT64 instead.
Ethereal supports proto_tree_add_item() if 64 bit integers with FT_UINT64
even on platforms with no native 64 bit integer support.
(though tehre is no tvb_get_guint64() or similar call)
Do also look at how proto_tree_add_item() handles FT_UINT64,
I do not remember if it can handle integers <8 bytes in size or if it
only handles integers that are exactly 8 bytes in lkength.
It sould be easy to modify it to handle <=8 byte integers in case
it does not do so already.
----- Original Message -----
From: "Jeff Morriss"
Sent: Saturday, March 22, 2003 6:27 AM
Subject: Re: [Ethereal-dev] malformed packet: proto_tree_add_item() cores
vs. exceptions?
Another (related) question:
proto_tree_add_item() generates a core (from 'assert()') if the item I'm
adding is, say, a UINT32 but I pass in a length > 4.
I wanted to rewrite "packet-sccp.c" to NOT do:
reference = tvb_get_ntoh24(tvb, 0);
proto_tree_add_uint(tree, hf_sccp_dlr, tvb, 0, length, reference);
but instead do:
proto_tree_add_item(tree, hf_sccp_dlr, tvb, 0, length, FALSE);
But the problem is that I'm using (what is supposed to be) the length of
the parameter from the SCCP message, but it can be very wrong if, for
example, "mtp3.standard" is set incorrectly for the current capture.
The problem I have is that with the existing code I get "malformed
packets" and with the new code I get cores (which aren't conducive to
allowing me to change the "mtp3.standard" setting).
Is it possible that 'proto_tree_add_item()' could generate an exception
(instead of a core) in this (and similar) cases?
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
