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

[Ashok Narayanan <ashokn@xxxxxxxxx>]

Gilbert Ramirez writes:
 > 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.

Release it already, so I can send in my diffs!!

 > 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. 

I don't think this is too much of a con. Especially if we discard the
"pcap-like" syntax altogether and go to a C-style expression (my pet
bugbear). The reasons are

- C expressions are known to one and all (including people who know
pcap-style expressions). There's no learning curve involved.

- pcap-style expressions are not known to many people. There is a
learning curve involved. I, for one, keep forgetting that 'eq' stuff
(no matter how simple it may be)

- pcap-style expressions have fundamental problems. For example, since
the character space of variable names is the same as the character
space of operators, "space" becomes a significant character in
pcap-style expressions. This is unnecessary, irritating, and not a
problem in C-style expressions.

- pcap-style expressions don't have coercion like C-style
expressions. For example, there's really no need for a '?' or 'exists' 
operator. You could just say "rsvp && rsvp.path.session.addr==127.0.0.1", 
and the initial "rsvp" would be an integer value coerced into an
expression result (boolean). 

In short - throw away pcap-style expressions!!

 > A filter-creation GUI for either filter-language, or both,
 > would help the situation for beginning users. 

Sure. That's important.

 > A translator to convert from one to the other *might* be possible.

That's not hard to write, although I don't see much need for one. Do
people really have these huge libraries of pcap expressions stored
away as filters? Especially given that pcap had way fewer variables to 
be filtered on?

 > 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.

Actually I've been giving some thought to protocol dissectors being
dynamically loaded. My thoughts:

1) The current protocol registration stuff is necessary but not
sufficient. I think you can commit this without having to change or
rewrite much later.

2) We need a bunch of additional registration stuff and a more general 
set of callout hooks. For example, we'll need some way in which a
module can indicate to Ethereal what packet it'll accept, like 
"ip protocol 46", or "udp packets addressed to port 37"

3) We need a generic method to walk a TCP connection (and please don't 
say this poses a security risk because it allows users to
snoop!). This would be useful to walk TCP-based protocols (I have one
I am interested in writing a sniffer for). This may come even before
the dynamic module loader, but it will definitely be part of the
API. I've started something in this direction, but have not gotten
very far.

-Ashok


-- 
--- Ashok Narayanan ----------------------------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387