On Jul 14, 2009, at 10:59 AM, arno wrote:
The problem is that many parts of the protocol do not always consist
of
the same amount of bytes. Therefore the bytes have to be decoded that
way (java code):
int decode(bytestream stream){
int b = stream.readByte();
int t = b;
while(b > 127){
b = stream.readByte();
t = (t << 7)) | b;
}
return t;
}
Sure looks similar to ASN.1 BER's encoding of integral values.... (If
it *is* ASN.1-based, look at using asn2wrs. ASN.1 BER probably isn't
the only protocol encoding scheme that does variable-length numbers
that way, however.)
Do get the right value is not the problem, but to register the header
field and to make it filterable. When I try to register it with the
array hf_register_info I have to specify a data type like FT_UINT8.
But
setting up the header fields with the right amount of bytes of tvb
when
dissecting the packet results in a wrong value, because the bytes have
to be encoded in the way I`ve mentioned it.
Is there a possibility to register a header field with e.t. FT_UINT32
and changing the value afterwards?
No. The field type is common to all instances of the field; it's not
per-instance.
*However*, it's not as if every field of type FT_UINTn *has* to take
exactly n/8 bytes; you could, for example, have an FT_UINT32 field and
put into it a value that's stored in fewer than 4 bytes. (That's how
ASN.1 BER-encoded protocols handle this.)
Or is it possible to filter header fields that are added with
proto_tree_add_text
No.
or add_value?
If by "add_value" you mean, for example, "add_uint" - e.g.,
proto_tree_add_uint - the answer is "yes". You don't *have* to use
proto_tree_add_item to have a filterable field.
Another way
could be to get the specified bytes of tvb, to encode it the right way
and then wright it back to tvb, but i did not found a possibility to
do
that.
There is no such possibility; tvbuffs are, by intent and design, read-
only.
I would be very glad to hear any suggestions.
Making the field FT_UINT32 - or FT_UINT64 if it's likely to have
values > 2^32-1, or FT_INT32 if it's signed, or FT_INT64 if it's
signed and likely to have values > 2^31-1 or < -2^31 - and using
proto_tree_add_uint() after fetching the value is probably the best
idea.
For better or worse, we don't have a FT_INT and FT_UINT (with no "n")
that can handle arbitrary-size integral values, which, at least in
theory, could be required by protocols using at least some ASN.1
encodings, as well as by your encoding.
