----- Original Message -----
From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
To: "Andrew Feren" <aferen@xxxxxxxxxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Sent: Wednesday, August 27, 2003 9:48 AM
Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
> SNMP is a good example of the difficulties of a very good machine
generated
> dissector.
OK I'll grant this, but I think you missed the point that was hidden in my
poorly choosen example. Olivier stated better when he said:
IMHO there are 3 issues discussed here:
1. Make up the data stream (conversation, reassembly)
2. Break up packet data in protocol fields (dissection)
3. Give an interpretation of the dissected fields (interpretation)
> One example:
> A very good SNMP dissector should be able to find where an ARP table
> is described in the SNMP transactions.
> The content of this ARP table should be used to populate ethereals
internal
> table for ethernet to ip address resolution.
> Data inside conversations of one protocol will contribute to the state and
> relations of packets for other protocols.
Does your dissector really need to understand the encoding of the SNMP
messages to solve this problem or would it be enough to get values from an
other entitiy that understands the encoding. What I think can be done
successfully is generate some code to solve issue two. As long as you only
interact with this code through a well defined interface while solving issue
three you should be able to regenerate the code for 2 without needing to
change the code for 3.
In the example I gave rather than understanding packet encoding (field
names, types and values) the modules understood how to request/set objecst
from/to a device and what the OID (as opposed to offset) was for each
object. As MIBs were updated we would rerun the tool to generate the module
that understood that MIB. After a recompile everything worked exactly as
before. Next we would revisit the code that interpreted the values. The
information's presentation and interpretation would be modified as needed.
OK now that I have typed all this and thought while I typed I do see one
issue (I'm not sure if it is more pro or more con). It seems likely that
different versions of a protocol might require one dissection module for
each version. This may mean a lot of extra code instead of a few special
cases in todays dissectors. On the other hand this may make the code a lot
cleaner. I'll give this some more thought.
-Andrew
