On Feb 16, 2014, at 2:09 AM, Dmitrij K <kdiman@xxxxxxx> wrote:
> I have corrected that by:
>
> // for sz
> tvb_memcpy(tvb, (guint8 *)&ldata, offset, 2);
That will either give you the wrong answer on a little-endian machine (such as a 32-bit x86 or x86-64 PC) or on a big-endian machine (such as a PowerPC/MIPS/SPARC-based box under most operating systems).
Either the field is:
defined as big-endian, in which case you should use tvb_get_ntohs();
defined as little-endian, in which case you should use tvb_get_letohs();
big-endian in some packets and little-endian in others, in which case you need to somehow figure out what the byte order is.
It appears, from the other calls you're making, that the field is little-endian.
> proto_tree_add_item(my_tree, hf_hdr_sz, tvb, offset, 2, TRUE); offset += 2;
You appear to be using Wireshark 1.10.x (based on the line number in the assertion failure in your earlier message); in 1.10.x, the last argument to proto_tree_add_item() isn't a Boolean, it's an ENC_ value, so that should be
proto_tree_add_item(my_tree, hf_hdr_sz, tvb, offset, 2, ENC_LITTLE_ENDIAN); offset += 2;
> // for e_flags:
> proto_tree_add_item(my_tree, hf_hdr_e_flags, tvb, offset, 2, TRUE); offset += 2;
The same applies there:
proto_tree_add_item(my_tree, hf_hdr_e_flags, tvb, offset, 2, ENC_LITTLE_ENDIAN); offset += 2;
> // for magic3:
> proto_tree_add_item(my_tree, hf_hdr_magic3, tvb, offset, 1, FALSE); offset += 1;
That's a one-byte numerical field; the ENC_ argument is currently ignored, but the convention is to say
proto_tree_add_item(my_tree, hf_hdr_magic3, tvb, offset, 1, ENC_NA); offset += 1;
The key fix was replacing "-1" as the length field in the above call with "1", as per my other mail.
