[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ethereal-dev
Subject:    Re: [ethereal-dev] Ethereal on SINIX machines
From:       Guy Harris <guy () netapp ! com>
Date:       1999-09-30 18:10:53
[Download RAW message or body]

> I would like to help with the further development of Ethereal. I work for a
> UNIX networking company mostly on NFS, and so I will provide full dissection 
> routines for the RPC layer and the portmapper, mount, lock manager, and
> NFS protocol.

...which means "port 111 or 2049" won't work as a way to identify RPC
requests; the heuristic I used in another program was:

	the 4-byte big-endian quantity at the offset where the
	"rm_direction" field of the RPC header would be is 0 (CALL) or 1
	(REPLY);

	if it's 0, the 4-byte big-endian quantity at the offset where
	the "rm_call.cb_rpcvers" field of the RPC header would be is 2
	(RPC V2 being the only version out there);

	if it's 1, the 4-byte big-endian field where the XID of an RPC
	request would be matches that of a call we've already seen;

and, for a call, the program and version number are those of a program
and version we know about.

"snoop" probably does something similar, except that the "are those of a
program and version we know about" appears not to be done, as I think
I've seen it decode RPC data for a program/version it didn't further
decode.  I was just a bit nervous that "0 at offset XXX, 2 at offset
YYY" wasn't sufficient to avoid false hits.

Note also that, of course, you'll also have to remember calls - not only
to recognize RPC replies, but also to *dissect* RPC replies, as RPC
replies have only the XID of the request, they don't have the program,
version, or procedure number of the request.

(This is similar to what the SMB dissector will have to do for TRANSACT2
replies; you might want to talk with Richard Sharpe here.  Note that
whatever table you use to remember calls should, of course, remember the
network-layer address and port number whence the request came, as XIDs
aren't globally unique.)

[prev in list] [next in list] [prev in thread] [next in thread]