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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
