Re;
doc/README.heuristic | 10 +--
+ * but ONLY do this if your heuristic sits directly on top of UDP
or TCP (ie, you did heur_dissector
+ * otherwise you'll be overriding the dissector that called your
heuristic dissector.
I think this is not correct. There is at least one "transport" protocol
other than TCP & UDP (i.e., DCCP) which currently has a heuristic table
and calls 'try_conversation()' and thus heuristic sub-dissectors can use
conversation_set_dissector().
I think, in theory, any protocol associated with the known
'port_type's [1] can establish a conversation for that port_type and
then have heuristic sub-dissectors which can call
conversation_set_dissector().
In actuality, only a few dissectors currently do so.
How about the something like following wording:
... but only do this if your heuristic sits directly on top of
(was called by) a dissector which established a conversation
for the protocol "port type". IOW: directly over TCP, UDP, ...
Looking at the Wireshark dissectors: I see at least one
possibly problematical case:
packet-soupbintcp has heuristic sub-dissectors and uses
try_conversation() even though it actually uses (I think) the
conversation established bu packet-tcp.
I thinks this means that if packet-tcp has "try heuristic first" that
things won't work right.
I'll have to research this further.
Bill
[1]
/* Types of port numbers Wireshark knows about. */
typedef enum {
PT_NONE, /* no port number */
PT_SCTP, /* SCTP */
PT_TCP, /* TCP */
PT_UDP, /* UDP */
PT_DCCP, /* DCCP */
PT_IPX, /* IPX sockets */
PT_NCP, /* NCP connection */
PT_EXCHG, /* Fibre Channel exchange */
PT_DDP, /* DDP AppleTalk connection */
PT_SBCCS, /* FICON */
PT_IDP, /* XNS IDP sockets */
PT_TIPC, /* TIPC PORT */
PT_USB, /* USB endpoint 0xffff means the host */
PT_I2C,
PT_IBQP, /* Infiniband QP number */
PT_BLUETOOTH
} port_type;
