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 ?
Q2: It seems reasonable to me to add code
to dissector_add and friends to validate the arguments:
handle != null
"pattern" (key) not already in the dissector table
Is this OK ? (If so, I'll add the code).
(On a somewhat separate note: I see that multiple registrations
happen for udp and tcp port 0.
I'm still looking at these to understand and to see if OK.)
