Wireshark · Ethereal-dev: Re: [ethereal-dev] Table-driven packet dissection?

[guy@xxxxxxxxxx (Guy Harris)]

> SPECIFICS
> 
> I propose having a table driven approach. At any protocol level, from
> FRAME_TYPE to the highest (eg, SMB type) we would have a table that
> contains things like:
> 
>   Protocol name
>   Offset into packet and length
>   Series of (value, dissect routine, next level table 3-tuples)

What would the interpretation of the latter two things be?

For example, what would the "value" be in the table in the second item?

> Although obviously, for this last, we will want a more efficient structure
> than the obvious.  Perhaps minimal perfect hashing will be needed in some
> cases.
> 
> Routines would be registered in tables, and we would have a hierarchy,
> something like:
> 
>    /ethernetV2/IP/TCP/SMB 
> 
> and a series of linked tables.
> 
> At each level, when a routine is called, it is passed the next level table
> if any, otherwise NULL.
>   
> A routine is defined like:
> 
>    dissect_IP(packet, next-table, gtk-pointers it needs ...)
> 
> There will need to be a set of routines to manage the dissect tables.
> Routines to add tables, add elements, etc.  I think there will be a need to
> add a routine dynamically to handle things like TFTP, etc.
> 
> So, has it all been done before?  Am I just blowing hot air?  Etc.

Microsoft Network Monitor uses a scheme wherein

	1) packet dissectors are loaded with the Win32 moral equivalent
	   of "dlopen()" ("LoadLibrary()");

	2) a (text) configuration file specifies, for each dissect
	   routine, either a "follow set" (other dissect routines that
	   should be called with what's left of the packet after the
	   specified dissect routine has said "it's one of mine" - for
	   example, the NetBIOS dissect routine has SMB and Microsoft RPC
	   as its follow set) or a "handoff set" (where the dissect routine
	   specifies which particular dissect routine to call next (for
	   example, the TCP and UDP dissect routines handoff sets list port
	   numbers and dissect routines).

Dissect routines do not call the next level's dissect routine, that's
done by common code.

Unfortunately, to handle ONC RPC, that'd force you to use follow sets
for TCP and UDP, given that there are only two ONC RPC protocols with
assigned port numbers (portmapper/rpcbind and NFS), and others are of
interest (lock manager, NIS, NIS+, etc. - they're of definite interest
here at NetApp, at least), and given that I don't *think* you can
specify both a follow set *and* a handoff set for a given protocol
(perhaps you can, though, which would be good).

(This means that basing the decision purely on port numbers isn't
enough; we have to allow some packet dissectors to do a heuristic check
of the payload, as well.  We already have that for the CORBA GIOP in
TCP; a general mechanism would be nice.)

The TFTP dissect routine would presumably, when it sees a request to the
TFTP port, add the source port of that request as a TFTP port - and,
presumably, mark it as meaning TFTP *only when coming from the host
whence the request came*.  We might also want a way to *delete*
transient handoff-set entries such as that, so that they don't stick
around once the TFTP conversation is complete.

This probably works better if dissection is done in the order in which
packets arrive; that's also needed for matching ONC RPC requests and
replies (which is necessary because ONC requests contain the procedure
being called, but ONC replies do *not* - you have to find the request
with the matching transaction ID to figure out the procedure being
called, and you need the procedure numbers so you know how to decode the
reply).

(Speaking of "conversations", the ability to follow conversations -
which are, at least in the simplest cases, connections for TCP, but
which have to be identified by higher-level protocols in UDP - would
probably be useful; we can already follow connections, but the ability
to follow UDP conversations would probably also be useful.)

Note also that the ability to add, *from the UI*, or by editing a
configuration file, new mechanisms for identifying which higher-level
protocol the payload in some lower-level protocol is, would be useful.

Around here, we'd want, at minimum, to specify ports other than 80 and
8080 for HTTP, so we can analyze traces going through a proxy cache.

"tcpdump" has facilities to force packets that match a given BPF
expression to be interpreted as

	ONC RPC (but that's better handled by a built-inheuristic, I
	suspect);

	RTP

	RTCP

	VAT

	WB

Network General Sniffers let you specify rules that let you match on
source and/or destination addresses and/or source and/or destination
ports to force a packet's payload to be treated as a particular
protocol.