Bill Meier wrote:
After adding a little validation code to dissector_add I've found that
there are currently at least two cases where multiple dissectors are
registered to the same non-zero tcp or udp port:
=====
udp.port: dsctr: cpfi; key 5000 already registered to: airopeek
udp.port: ddctr: tapa; key 5000 already registered to: cpfi
result:
cpfi & airopeak registrations lost (as well as a little memory leak)
=====
tcp.port: dsctr: tcpencap; key 10000 already registered to: ndmp
result:
ndmp registration lost ....
----------------------
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.