Hi, I am trying to write my own dissector and so far it works pretty well. However, I am using value_string but it does not work as expected. By studying other dissectors, I see that most value_string arrays look like the following:
Instead of having integers as the value, I want to have characters, example:
My header field is the following:
The idea behind having FT_STRING is that it should show the char value from foo2. However, this does not work. I get the following error message "Err Field 'FIELDNAME' has a 'strings' value but is of type FT_STRING (which is not allowed to have strings)" If I change from "FT_STRING, STR_ASCII" to "FT_UINT8, BASE_DEC" it works but it shows the ascii decimal value (example 65 instead of 'A'). Is there a way I can accomplish this? As previously mentioned, all dissectors I have studied only have integers as their values and not chars. Does that mean my idea is not possible? I also want to point out that I read this which to me makes it sound like the value_string stuff does not support FT_STRING. This question is marked "community wiki". asked 21 Nov '16, 05:54 hokosha |
One Answer:
Indeed value_string arrays are designed to match a value (understand a number) and associate with it a string. FT_STRING is designed for fields containing a string, and cannot work with value_string arrays. What you can eventually do is to use either the proto_tree_add_uint_format_value or proto_tree_add_string_format_value function to fully control the display. Note that it will not impact the filter content. Have a look at doc/README.dissector for more details. answered 21 Nov '16, 06:18 Pascal Quantin |
You may also want to check out another type of value_string called a string_string. Unfortunately it seems this isn't yet supported in hf's (i.e., there's no VALS*() macro to allow your string_string to be put in the hf) but it should help...
(I wonder why string_string's aren't supported in hf's...)
Note that master tree now supports a FT_CHAR, that could be used in this case:
"FT_CHAR An 8-bit ASCII character. It's treated similarly to an FT_UINT8, but is displayed as a C-style character constant."