https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7715
--- Comment #12 from Martin Kaiser <wireshark@xxxxxxxxx> 2012-09-13 04:57:48 PDT ---
(In reply to comment #8)
> (In reply to comment #7)
> > Hi,
> > (In reply to comment #6)
> > > Basically, you want to know if the packet is coming
> > > from you blutooth protocol and change the col_info entry accordingly.
> > > Why don't you look at proto->layer_names for this?
> > s/proto->/pinfo->layer_names/?
> > I'm not sure if you can use pinfo->layer_names.
> > We are only constructing layer_names when frame.protocols is referenced (ie
> > building visible tree or filtering "frame.protocols")
> > [packet-frame.c:315-331, commit r29733].
>
> Hmm, I've been thinking about a "pre-filtering" function to speed up filtering
> where you would find
> the protocol tied to a filter string, if any. And then skipp that frame
> if the protol is not found in the layer_names. Of course that depends
> on the list beeing built and saved in frame_data, one could have a list of
> protocol id's rather than the GString list. At the first pass all
> packets must be read.
>
> Possibly call_dissector_work() could be changed to build the list independent
> of
> the frame dissector, I'm not sure the processing cost is that high.
Jakub: thanks for your explanation, I didn't realize that layer_names isn't
always populated. The TCP dissector uses it, but inside an if (tree) { }
For the protocols I worked on, I often wanted to see the list of lower-layer
protocols, similar to Michael's use case. Having a generic solution for this
would be nice. (I have no idea about speed implications.)
Anders: you mean we replace the GString proto1:proto2:... with a list of IDs
and the frame dissector creates the string for its tree (if required)?
Best regards,
Martin
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
