From: Philippe Vivarelli
Hi,
I developed 2 plugins for our proprietary ETH protocol (CSM_ENCAPS 0x889b)
and CSM_API.
The CSM_ENCAPS plugin calls the CSM_API one.
When I open a trace messages from the CSM_ENCAPS plugin are correctly
printed out in the col info, but the one I want to print from the CSM_API
plugin are not printed unless I apply a filter (i.e eth.type==0x889b).
Does someone know why ?
You probably added too many "if(tree)" statements. When a filter is applied,
every "tree" evaluates to TRUE. There are some hints about correctly using
"if(tree)" in README.developer. Quoting from that file:
A protocol dissector can be called in 2 different ways:
(a) Operational dissection
In this mode, Ethereal is only interested in the way protocols
interact, protocol conversations are created, packets are reassembled
and handed over to higher-level protocol dissectors.
This way Ethereal does not build a so-called "protocol tree".
(b) Detailed dissection
In this mode, Ethereal is also interested in all details of a given
protocol, so a "protocol tree" is created.
Ethereal distinguishes between the 2 modes with the proto_tree pointer:
(a) <=> tree == NULL
(b) <=> tree != NULL
In the interest of speed, if "tree" is NULL, avoid building a
protocol tree and adding stuff to it, or even looking at any packet
data needed only if you're building the protocol tree, if possible.
Note, however, that you must fill in column information, create
conversations, reassemble packets, build any other persistent state
needed for dissection, and call subdissectors regardless of whether
"tree" is NULL or not. This might be inconvenient to do without
doing most of the dissection work; the routines for adding items to
the protocol tree can be passed a null protocol tree pointer, in
which case they'll return a null item pointer, and
"proto_item_add_subtree()" returns a null tree pointer if passed a
null item pointer, so, if you're careful not to dereference any null
tree or item pointers, you can accomplish this by doing all the
dissection work. This might not be as efficient as skipping that
work if you're not building a protocol tree, but if the code would
have a lot of tests whether "tree" is null if you skipped that work,
you might still be better off just doing all that work regardless of
whether "tree" is null or not.
Your plugins probably skip dissecting parts of the packets used to update
the INFO column with an if(tree).
Best regards,
Olivier