Hi, I am creating dissectors for some proprietary protocols in which I have added preference to specify the port numbers for the dissector. Apart from that I have also registered my dissector to some well known port numbers. My question is that what would happen to the port numbers on which the dissector is registered by default by me (in the lua script) if I go to the dissector preference and change the port numbers from there. Thanks. asked 12 Aug '16, 09:34  shobhit_garg91 |
One Answer:
Every registration in a dissector table has to be explicitly add and removed. The usual pattern is to get the preference (or default value). and register that. When the preference chances you have to remove the previous registration and put the new one in. There are enough examples of this for the UDP and TCP dissectors. answered 12 Aug '16, 10:14  Jaap ♦ edited 12 Aug '16, 11:06  sindy |
Hi Sindy, Thanks for your inputs. I am dealing with the issue of removing the ports that the dissector is registered to. I know that i can use remove() to remove the dissector from specific port numbers. I wanted to know if there is any way in which I could remove my dissector from all the registered ports and then re-register the dissector based on the port numbers specified by the user in preferences section. Please let me know if there is anything I could do in this regards. The major issue is that I have created multiple dissectors, and I need to change the port numbers which they listen to dynamically (from preferences). I am able to add preferences and listen to change in preferences using the PROTOCOL.prefs_changed(). I want remove all the port numbers the dissector was registered for previously and register the protocol to the new port numbers specified in the preferences.
Thanks.
First, all tributes belong to @Jaap, not to me - I have just slightly clarified his original wording.
I don't know any "drop the whole dissector table contents" method, but is not really clear to me why would you need to generally deactivate the original dissectors which are not in conflict with your assignment of the ports. I mean, if your protocol uses TCP port 23, you need to replace the corresponding row in
tcp.portdissector table, but if it doesn't, why should you disable processing of telnet if it is not in conflict with your use of the port?So my approach would be to replace only the mappings for those ports which I need to modify, and even to remember the original mapping for each of them so that I could restore it to the table e.g. if I find out that I've chosen that port number for my protocol by mistake.
OK, I see your point now after reading your other question. For TCP it is normally assumed that high port numbers are used as ephemeral ones, and low ports are "well known" ones, so this type of conflict doesn't happen.
Wireshark uses a preference "try heuristic dissectors first" which suggests that it can offer the same piece of data to another dissector if the first one couldn't dissect them. So to implement the hierarchy, each of your dissectors has to check both the source and the destination port number, and if it finds out that such combination favours another dissector, do nothing and return 0 to indicate that to the invoking dissector, which will then try the next dissector based on match of the other port number. This, inevitably, requires chaining of existing dissectors with such detectors (so that the telnet dissector from my example above would only be allowed to do its job if no higher priority dissector matches the other port of that packet).