Ethereal-dev: Re: [Ethereal-dev] Re: ASN.1 File Dissection

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

From: Graeme Lunt <graeme.lunt@xxxxxxxxx>
Date: Sun, 27 Nov 2005 19:18:44 +0100
Anders,

> First of all I haven't looked at the code yet (lack of time) and was hoping
> some one else would comment.
> > > The patch also includes a BER preference to allow the user to
> > > specify a file that contains OID information for OIDs that Ethereal
> > > hasn't already encoded.
> I have been thinking about changing the "OID string to Name" translation to
> use the SNMP code as it can do "partial" name translations.

That will certainly give the user some context.

One thing I've found is that there is doesn't seem to consistent way
to name an OID. Having dumped all the names from the different
modules, there is a wide variance.
Do you think it would be worthwhile trying to describe how an OID
should be named in Ethereal? For example, should  2.2.1.0.1 be named:

"id-as-acse" - as defined in the standard
"acse" - (id-as if fairly superfluous)
"{joint-iso-itu-t(2) association-control(2) abstract-syntax(1)
apdus(0) version1(1)}" - to be complete

Personally I prefer the short form.

> There has also
> been discussions about making a new FT, FT_OID where this would fit nicely
> IMHO if that is done one could always make a fake MIB to define OID
> translations or we should keep one for the translations we are already
> doing.

Interesting. I had looked at adding a new FT for OIDs as I wanted to
be able to add a menu item ("Field Info") to the packet info menu.
This would bring up a description of an OID - with the URL specified
as a preference (e.g. http://oid.elibel.tm.fr/2.2.1.0.1 or
http://www.alvestrand.no/objectid/2.2.1.0.1.html).

My inexperience with asn2eth put me off, so if someone else was to
implement an FT_OID ...

> > > There are a number of circumstances when it useful to dissect an ASN.1
> BER
> > > encoded file.
> > > For example, a X.509 certificate, a PKCS#12 file or a lump of X.400
> content
> Isn't this what the ASN.1 plugin does with the aid of some tool?

The plug-in still requires the ASN.1 to be wrapped in a TCP stream or
UDP packets and displays the ASN.1 differently to the specific
Ethereal dissector. For example, if I have a certificate in a file it
will not be dissected in the same was as a certificate in some CMS.
Also it requires you to do some compiling with SNACC.

> > > * dissect_unknown_ber() has been significantly upgraded to handle
> arbitary
> > > ASN.1
> Please submit as a separate patch.

OK.

Graeme