Ethereal-dev: Re: Fw: [Ethereal-dev] SMBpatch for read/write and x

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Bernd Becker <bb@xxxxxxxxxxxxxxx>
Date: Thu, 29 Nov 2001 08:36:39 +0100
Hi,

On Wed, 28 Nov 2001 15:25:08 -0600 Gilbert Ramirez <gram@xxxxxxxxxxxxxxx> wrote:

On Wed, 28 Nov 2001 15:18:40 Ronnie Sahlberg wrote:
Subject: Re: [Ethereal-dev] SMBpatch for read/write and x


 I assume it is an optimization, when inside proto_X, only look at hf_X
when
 matching display filters (we have quite a number of displayfilters now)
 Perhaps the displayfilter stuff should always scan ALL hf_variables
...
The display filter code can easily be changed to find an field under
*any* protocol, not just the one for which the field was registered.

In proto.c, proto_get_finfo_ptr_array() and
proto_check_for_protocol_or_field(), and perhaps some of their static
helper functions, need to be changed to scan the entire tree instead of
just a particular branch.  If this is what we want, I can make the change.

--gilbert

I just want to point out that we have the same problem with filtering in the
GIOP dissectors. Right now the tree built up in packet-giop.c and any plugin
GIOP dissectors generated via idl2eth (e.g. Cosnaming) looks like this:
+ General Inter-ORB Protocol
+ General Inter-ORB Protocol Request
+ Cosnaming Dissector Using GIOP API

The first subtree contains (more or less) only the header fields of the GIOP
message, and those few are the only fields that are searchable right now.
The second subtree (GIOP request or reply) is generated by a dissector not
registered as a protocol and uses the fields registered with the first subtree. The third subtree is generated by the plugin dissector (if available). This is actually registered as a protocol but does not register any fields of its own, but uses the fields of the first subtree. So, with this layout, nothing in the
second and third subtrees is searchable via display filters!
I have solved the problem here for me by changing the tree structure to
+ General Inter-ORB Protocol
   + General Inter-ORB Protocol Request
   + Cosnaming Dissector Using GIOP AP

The patch is very simple, but I haven't submitted it because I don't really
like it that much because now you have to expand the tree in order to see the
interesting stuff. I have discussed this with Frank Singleton, and we were
starting to search for a maybe better solution.
So, I think a solution as suggested by Gilbert above would be great!

Cheers,
Bernd
P.S: As this is my very first post to the list, let me just say Thank You
to all of you for this great tool!!!