> > 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?
Is the idea that the offset into the packet, and the length, specifies a
field in the packet, and the values are values for that field, with the
dissect routine being the dissect routine to use if the field has that
value?
If so, note that there may need to be a way to look at more than one
field, and to do multiple tests ANDed or ORed together, to handle some
heuristics (I suspect you'd have to do that for ONC RPC; I don't know
what heuristic Sun's "snoop" uses to detect ONC RPC requests and
replies, but the one I used in another program was:
to detect a call, look for 2 in what would be the RPC protocol
version field, and then look for a known program and version
number - that, unfortunately, requires the ONC RPC dissect
routine to know what ONC RPC-based protocols are to be
dissected, and can't detect an RPC call to an unknown
program/version;
to detect a reply, extract what would be the transaction ID, and
see if we saw a call with that XID - as indicated, you need to
find the call *anyway*, so you know what
program/version/procedure this is a reply to).
Note also that you may need to give the field a type; if the field is
numeric, you'd have to worry about byte order, but if it's text - e.g.,
the "GIOP" in the GIOP protocol, or the "\377SMB" in SMB - you don't.
(Not an issue if, when the table is set up, you put stuff in the "right"
byte order, although whatever you use to initialize the table - a text
file, or whatever - *would* have to worry about byte order.)
> (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.)
...although a conversation might involve more than one TCP connection,
e.g. a conversation between an NFS client and an NFS server, over TCP,
might include not only NFS traffic but also lock manager and mount
daemon traffic.
