Wireshark · Ethereal-dev: [ethereal-dev] proto_tree discussion

[Gilbert Ramirez <gram@xxxxxxxxxx>]

I am almost ready to release the final patch demonstrating the new
proto_tree implementation. Perhaps tonight or tomorrow. I haven't touched
the issues of filtering on string variables (regex!!!) or time variables,
but everything else is working well.

No one has mentioned any major problems with the implementation, so
I guess people are okay with it. Have people actually looked at it?
Probably not. :) That's why I want to produce one more patch and
be sure to discuss it. It is a _major_ change to ethereal's innards.

In order to start discussion on this, I'll present the following
list of pros and cons about this implementation of proto_tree and display
filters.


PROS
----
1. It allows you to filter on any field in the protocol tree. Depending on
how liberally we use the text-only function, this may read "it allows
you to filter on _most_ fields in the protocol tree".

2. No longer is this implementation "all-or-nothing". The transition
from old proto_tree to new proto_tree does not have to occur overnight.
Old proto_tree information will still be displayed in the GUI protocol tree,
it's just not filterable.

3. It finally allows the wiretap library to become a standard part of
ethereal, allowing everyone to read multiple file types. This was not
advisable before because wiretap had poor display filters.

4. The display filter language, besides having more fields to filter on,
is also more powerful than libpcap's. The following are currently
possible in the new display filter language (once the protocols
are converted to the new proto_tree implementation)

	Check bytes at any offset in any protocol
	frame[5:2] eq aa:bb
	ipx[0:2] ne ff:ff

	Check bytes at any offset from the beginning of any field
	eth.dst[0:3] eq 00:00:83
	
	Compare variables against variables (w/in the same packet, of course)
	bootp.client_hwaddr ne fddi.dst
	ip.dst eq ip.src

	The existence function (w/ unary operator 'exist', 'exists', and '?',
		which are synonyms for each other)
	? ipx
	exists ip
	exist trmac

	Ability to check multiple ocurrences of fields in proto_tree
	tr.rif_ring eq 0x0c2		(a packet can have more than one
					tr.rif_ring)
	bootp.option eq 52		(a packet can have many bootp options)
	fddi.src eq 01:02:03:04:05:06	(checks against non-bit-swapped
					and bit-swapped versions, both of
					which are stored in the protocol_tree,
					except that one is invisible)

CONS
----
1. The display filter syntax in ethereal would be different from and
incompatible with the capture filter syntax (libpcap). Users would have
to know both. A filter-creation GUI for either filter-language, or both,
would help the situation for beginning users. A translator to convert
from one to the other *might* be possible.

2. More memory usage for proto_tree.

3. Ethereal display filters are slower than libpcap display filters, since
libpcap uses byte-compiled BPF instructions. I'm using lots of C code.


I believe that the pros outweigh the cons. The one 'cons' that troubles me is
the incompatible filter language. But the power it gives the user is
tremendous --- I believe we should move in this direction.

Ashok brought up the point that converting an entire protocol to the new
proto_tree implementation increases size, either executable size or
LOCs. This is true. Perhaps the ability to filter on every single field
in the protocol tree should not be the goal for ethereal. Perhaps the
goal should be the ability to filter on all useful fields. But utility
is in the eye of the user...

How about compatibility with a future "ethereal module" loader? I believe
this implementation to be compatible with that. The protocol registration
is done locally, from within each dissector. That decentralization helps
when dynamically loading dissector modules. I haven't given much thought
to modules--- can anyone see any incompatiblities? I'd hate to convert
all the dissectors to this new proto_tree implementation and then have
to go back and do it again when we have dynamic modules.

Thoughts?

--gilbert