I have a dissector that works correctly and I'm working on some usability features. Namely, I want to be able to filter on a 64 bit value using a text label. For example, I would like to be filter on all orange objects in my protocol. e.g. myproto.id == orange where orange has an id that is 64 a bit integer. I've looked in the manual section 9.2.3. "Improving the dissection information" and tried to follow that. But I'm getting the error "Err Field 'ID' (myproto.id) has a 'strings' value but is of type FT_UINT64 (which is not allowed to have strings)" My code looks like static const value_string IDnames[] = { { 1736646964, "Orange" }, { 1022267019, "Red" }, { 2033618120, "Green" }, }; My header fields looks like { &hf_IDPath, { "ID ", "myproto.id", FT_UINT64, BASE_DEC, VALS(IDnames), 0x0, NULL, HFILL } }, Am I just going about this wrong way or is filtering by label on a 64 bit integer not allowed? I'm also curious about the behavior of Wireshark if it looks up the id and it isn't in the array of value_strings. asked 09 Nov '10, 14:38  tlann |
One Answer:
The value_string stuff was added to Wireshark (back when it was called Ethereal) before we had support for 64-bit integers (we didn't want to require that compilers support it then), so it didn't support 64-bit integers. This means that you can't associate a value_string table with an FT_UINT64 or an FT_INT64; so 1) you can't have protocol tree entries for those fields show a label based on the value and 2) you can't use labels when filtering on them. If you have a field that does support value_strings, and the field has a value_string, but the value of the field isn't in one of the value_string entries, the field will just be displayed with its numerical value, and possibly with the label shown as "Unknown". answered 10 Nov '10, 14:40  Guy Harris ♦♦ |
Thank you for your answer.
With 64 bit machines I could see more and more use for 64 bit value_strings in the future. Is there talk of supporting this in the future?
Preparing a parch with a new values_string_ext_64 and the needed supporting routines(match_.. etc) and submiting it at https://bugs.wireshark.org/bugzilla would be a good start.