Ethereal-dev: [ethereal-dev] New proto_tree patch

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

From: Gilbert Ramirez <gram@xxxxxxxxxx>
Date: Fri, 2 Jul 1999 01:46:52 -0500
Here is my latest patch showing the work on the implementation of
a better, redesigned protocol tree in Ethereal.  Last time I wrote I
said that I would work on converting the PPP and IP dissectors. Well, I
started the IP dissector, and then realized this:

The work on converting the dissectors from the old-style to the
new-style is a one-man-show until I finish the TCP and UDP dissectors.
Once I finish those, then everyone can help convert their favorite
protocol dissector to the new protocol tree implementation. (That's
assuming that the implementation I'm working on has enough merit to be
put into CVS and replace the old protocol tree routines in ethereal).

In order to get everyone to help in the code conversion, I really need
to sell this new design to everyone. So, instead of promising that some
day someone would write a display filter routine to take advantage of
the all the new data available in the protocol tree, I switched gears
and began writing the display filter routines. Once you see that, wow!,
you actually _can_ filter on every possible field, you start to like the
idea of a re-engineered protocol tree.

This patch has just a few fields in IP converted to the new protocol
tree (yes; I made sure that the src and dst IP addresses are in there),
but it has a fairly functional display filter routine.

The following operands are implemented:
	and, or, not, eq, ne, lt, le, gt, ge

e.g.,	ether.dst eq ff:ff:ff:ff:ff:ff or ip.src eq pow.zing.org

The following field-types are currently filterable:
	numeric (uint8, uint16, uint32), ether, and ipv4

When representing integers in the filter string, you can use decimal,
hex, or octal. (I'm using strtoul()):
	eth.len eq 10
	eth.len eq 0xa
	eth.len eq 012

There are many places where the display filter routines could be
improved. I know of many inefficiencies in the code; but I opted for
code clarity at this point rather than efficiency.

The "existence" function is not implemented. I want to be able to filter
on the existence of a protocol by naming it:
	ipx

I also want byte-ranges: frame[5:2].

And I *really* want alternations, like in Icon:

	(ip.src | ip.dst) eq 192.168.44.99
or
	tr.dst eq (c0:00:ff:ff:ff | ff:ff:ff:ff:ff:ff)
or
	(ip.src & ip.dst) eq (10.0.0.1 | 129.111.5.41)

:-)  But syntactic sugar will come later.

IPv4 addresses can be represented in dotted decimal or by hostname.
Right now, MAC addresses can only be represented via the "colon" hex
notation, but I'll add /etc/ethers resolution as well:
	ip.src eq pow.zing.org
	ip.dst ne 255.255.255.255
	ether.dst eq ff:ff:ff:ff:ff:ff

Fields that are numeric but have value_string representations must be
filtered by numeric value, but in the future you'll be able to say:
	llc.dsap eq 'snap'

One thing I didn't like was how the bitfields came out. For example, in
token-ring I have the following:
	Access Control (0x18)
	 000. .... = Priority = 0
	 ...1 .... = Frame
	 .... 1... = Monitor Count
	 .... .000 = Priority Reservation = 0

When I first fired up the GUI, I naturally typed in:
	tr.monitor_cnt eq 1

But nothing passed through the filter! Then I realized I had to shift my
value over 3 bits:
	tr.monitor_cnt eq 8

What to do... what to do...  Should I do the shifting for the user?

Anway, have fun with the patch. Feel free to post suggestions and ideas.
I'm interested in bug reports, too, but there are probably too many
bugs to report. I just noticed one in how tr.rif_ring is filtered... :(

I have put a gzipped tar file of the entire source at
http://www.xiexie.org/ethereal/ethereal-new.tar.gz
for those who don't have easy access to the CVS tree. Otherwise, the
attached patch is against the current CVS image.

Patch against a spare copy of your CVS image. Then run automake and
autoconf. When running ./configure, be sure to say:
--disable-snmp --with-wiretap

Wiretap is optional, but now that I think about it, I can't remember if
the place that hooks into the display filter routines is generic or
pcap/wiretap-specific. Just go ahead and use wiretap.

--gilbert

BTW,

Here are the fields and protocols currently converted to the new
protocol-tree implementation:

data

eth
eth.dst
eth.src
eth.dst_vendor
eth.src_vendor
eth.len
eth.type

fddi
fddi.fc
fddi.dst
fddi.src
fddi.dst_vendor
fddi.src_vendor

frame
frame.time
frame.frame_len
frame.cap_len

ip
ip.version
ip.hdr_len
ip.tos
ip.tos_precedence
ip.dst
ip.src

llc
llc.dsap
llc.ssap
llc.control
llc.type
llc.oui

null
null.next
null.len
null.family

tr
tr.ac
tr.priority
tr.frame
tr.monitor_cnt
tr.priority_reservation
tr.fc
tr.frame_type
tr.frame_pcf
tr.dst
tr.src
tr.dst_vendor
tr.src_vendor
tr.sr
tr.rif_bytes
tr.broadcast
tr.max_frame_size
tr.direction
tr.rif
tr.rif_ring
tr.rif_bridge

Attachment: eth-proto-2.diff.gz
Description: application/gunzip