Wireshark-dev: [Wireshark-dev] On the behaviour of dissector_add_uint_range_with_preference()
Hi list,
While working on change 24438 (TPKT: remove duplicate port setting) I’ve run into some behaviours of dissector_add_uint_range_with_preference() which need to be discussed. In short, the handling of the default values is inconsistent. Using this method allows you to remove the default, which gets restored to it when starting Wireshark again. These are the steps taken the reproduce. I’ve used a capture file from the SampleCaptures Wiki which contains TPKT.
TPKT dissector stripped of old preference settings (change 24438).
decode_as_entries file cleared out.
See how dissector_add_uint_range_with_preference() behaves.
Tested with both tpkt_module = prefs_register_protocol(proto_tpkt, NULL); and
tpkt_module = prefs_register_protocol(proto_tpkt, proto_reg_handoff_tpkt);
-------------------------------------------------------------------------------
1)
After startup TCP Port dissector table has 102 associated with TPKT.
This is due to the call to proto_reg_handoff_tpkt() containing
dissector_add_uint_range_with_preference() with the default port range.
Dissection ok.
2)
Change TCP port(s) preference of TPKT to 100-105.
The decode_as_entries file now contains entries for 100 to 105.
This includes 102, but it has no default protocol though (bug?).
Dissection ok.
3)
Open Analyze|Decode as... dialog. This shows the decode_as_entries file contents.
Entries for TCP port 100 to 105 are present, 102 has no default protocol (bug?).
Dissection ok.
4)
Remove entries 100 to 102 from the dialog and save.
The decode_as_entries file now contains entries for 103 to 105.
Dissection is gone.
5)
Restart Wireshark and load the same capture file.
The decode_as_entries file still contains entries for 103 to 105.
After startup TCP Port dissector table has 102 associated with TPKT also.
Dissection is ok.
Conclusion: The default dissection isn't retained while editing the Decode as...
list, but is restored after restarting Wireshark.
I’m not sure what the correct behaviour should be. I can imagine it to be to always mix in the default values, but I don’t know how that may interfere with other overlapping decode as settings from other protocols.
I have some other questions as well on this, but I thought to start off with this.
Thanks,
Jaap
