Jeff Morriss wrote:
Q1: Can anyone suggest the appropriate resolution of these conflicts ?
Does that (the registration loss + memory leak) still happen if the
dissectors are "new style"? I would think that converting them to "new
style" dissectors "should" be the answer but I didn't look into it.
Having dug a bit further into the three protocols I'm inclined to just
do a dissector_add_handle in the airopeek & cpfi dissectors leaving only
the tapa dissector registered on port 5000.
1. Currently it appears that the airopeek dissector can already only be
accessed via decode-as.
2. It also appears that the cpfi dissector can currently only be
accessed via decode-as (or by changing cpfi port preference).
In any case:
Two of the dissectors (cpfi and tapa) are already new-style.
The issue, unfortunately, is that currently all 3 dissectors explicitly
register themselves to udp port 5000 via dissector_add().
Since there's no checking in dissector_add for duplicate registrations
the net result is that the last dissector to register on udp port 5000
wins with the previous registrations being obliterated.
