Dueling Dissectors

Question

I'm guessing there are many ways to solve this, but so far I'm coming up dry...

I have two different dissector instances which differ in terms of a layer of protocol/wrapper which either exists or does not. Unfortunately there's no way to easily determine whether this wrapper exists which is why I had intend to create two dissector instances which differ chiefly in this regard.

The problem is that it seems that I cannot use the "enabled protocols" feature to effectively switch between which type of data should be expected. When I disable one of the two protocols it seems to not "fail over" to uses the alternative despite them both using the same registration methods (dissector_add_uint).

I've found that in order to "fail over" to the alternative dissector I need to actually remove the alternate plug-in from the search path; this is not a tenable solution.

So any suggestions on how to proceed? - Is there some way to do an effective parallel registration? - Are there callback methods I can register to be notified of enable/disable operations (so that I could register/de-register as a workaround) - Perhaps merging the two dissectors and governing behavior based on a preference is simpler?

Answer 1

0

Look into heuristic dissectors. They have to determine, after reading an initial part of the packet, it it's theirs to keep of that some other dissector may have a stab at it.

answered 16 Jun '17, 12:03

Jaap ♦
11.7k●16●101
accept rate: 14%

I gave some thought to attempting that, but was worried I might be painted into a corner in terms of performance. Particularly if I need to run CRC checks to be certain of a match, etc.

After consulting with some users I'm going to just go the preference route

(16 Jun '17, 13:09) wittynickname

A heuristic dissector doesn't necessarily have to run all the checks on each frame, it is enough to do that on a first one of each "session".

As for callback methods to be registered - the "core" normally invokes a dedicated function of your dissector code each time a setting is changed in the GUI (and once during initialization). I only write Lua dissectors where the function is called <protocol_object_name>.prefs_changed(), so you'll have to find out the equivalent if you use C.

(18 Jun '17, 03:08) sindy

Hm, it is not that easy. I did what I'd suggested and it didn't work: when I switched the preference "use" of one of the dissectors to false, which invoked a dissector_table:remove for it and I could see that the item has indeed disappeared from the dissector table listing, and then switched the preference "use" of the other dissector to true, the other one did not appear in the dissector table - while it does if the first dissector is removed from the plugins.

So it seems to me as if the <protocol_object_name>.prefs_changed() function is called for all protocols in alphabetical order each time a preference of any of them is changed.

In C it should be easy for you to check, before removing a dissector from the table, whether it is the one you've put there yourself (so you can remove it) or some other one (so you should not touch it). In Lua it seems impossible to me so far as the == test fails on both protocol_name and protocol_name.dissector.

(18 Jun '17, 11:36) sindy

Solved that by a workaround, so the whole solution in Lua now looks like this:

-- in the Main Code of the Module
local it_is_me = false
– Handling of Preference Changes
function my_proto.prefs_changed()
local my_dis_table = DissectorTable.get("parent_proto.selector_value")
if my_proto.prefs["use"] then
my_dis_table:add(value,my_proto)
it_is_me = true
else
if it_is_me then
my_dis_table:remove(value,my_proto)
it_is_me = true
end
end
end

(18 Jun ‘17, 12:23) sindy