How would I edit my custom dissector to make it decode bytes and display them as ASCII rather than hex or dec or any of the standard formats? asked 31 Jul '12, 14:13 bball2601 |
One Answer:
ASCII is a standard format - use a field of type answered 31 Jul '12, 15:13 Guy Harris ♦♦ showing 5 of 7 show 2 more comments |
I had tried that...when I used field types FT_STRING and FT_STRINGZ, nothing is displayed, and when I use FT_UNIT_STRING, I get an error saying: [Dissector bug, protocol PFCP: proto.c:1115: failed assertion "DISSECTOR_ASSERT_NOT_REACHED"]
I'm not sure if I possibly did something wrong. Here is my code dealing with this.
{ &hf_pfcp_ipAddressStr, { "PFCP IP Address String", "pfcp.ipAddressStr", FT_UINT_STRING, BASE_NONE, NULL, 0, NULL, HFILL } },
proto_tree_add_item(pfcp_tree, hf_pfcp_ipAddressStr, tvb, offset, 15, ENC_ASCII); offset += 15;
OK, this is a bit confusing. FT_UINT_STRING is for "counted" strings, where the string has an integral count of characters, followed by the characters. The length you specify is the length in
proto_tree_add_item()
is the length of the count in bytes, and it has to be between 1 and 4 bytes. In addition, you have to specify the byte-order of the count (ENC_ASCII|ENC_BIG_ENDIAN
orENC_ASCII|ENC_LITTLE_ENDIAN
), and to do theoffset += N;
you'd have to fetch the count yourself and add it to the offset.So what format is the string in?
I'm sorry I'm new to all of this, what do you mean by "what format is the string in"? And I believe the field type I'm going to be wanting to use is FT_STRING, if that makes any difference.
Is it:
15 bytes of ASCII characters, and always 15 bytes long?
0 to 15 bytes of ASCII characters, padded at the end with NULs (bytes with a value of 0);
an arbitrary number of ASCII characters, with a NUL at the end (so that it's not always 15 bytes long);
a 1-to-4-byte count of characters, followed by that number of ASCII characters (so that it's not always 15 bytes long);
something else?
Its 15 bytes of ASCII, always being 15 bytes. Its supposed to represent an IP address in the 000.000.000.000 format, each byte representing a digit or a period, always making it 15 bytes.
So 127.0.0.1 would be represented as 127.000.000.001?
OK, then what should work is
and
If that doesn't work, file a bug - and attach a sample capture that exhibits the problem and your dissector code, if possible, as that would make it a lot easier to debug.
I finally got it working. The packets I was using I had individually created with another program, and it seems I created them wrong. Once I tested it with a proper packet, it decoded properly.
Thanks for all your help.