["Andrew Feren" <aferen@xxxxxxxxxxxxxxxxx>]

While researching ASN.1 compiler vendors a year or so ago I only found one
vendor that provided ECN.  (I'm quite sure none of the free ASN.1 compilers
support ECN now nor are they likely too anytime soon.)  If you want to pay
for a compiler check out OSS Nokalva (http://www.oss.com/products/ECN.html).
This is, in my experience, a good company and product, but I don't think it
is the right solution for your problem.  I think generating dissectors from
an XML description or coding your protocol by hand is really the way to go.

-Andrew

----- Original Message ----- 
From: "John Bourke" <john.bourke@xxxxxxxxxxxxxxxxxx>
To: <ethereal-dev@xxxxxxxxxxxx>
Sent: Tuesday, October 07, 2003 7:30 PM
Subject: RE: [Ethereal-dev] Mission to ASN.1 ethereal dissector generator


Folks,

It looks like ASN.1 with (Encoding Control Notation) ECN is the way to go to
have a generic text mechanism for specifying protocols, which have bit
encodings and optional elements and other such goodies.

It looks like I'm going to have to go down this route, or code my protocol
by hand.

Has anyone come across ECN ?

http://asn1.elibel.tm.fr/en/ecn/tutorial.htm


john


-----Original Message-----
From: Fulvio Risso [mailto:fulvio.risso@xxxxxxxxx]
Sent: 27 September 2003 18:02
To: Chris Waters; John Bourke; ethereal-dev@xxxxxxxxxxxx
Subject: RE: [Ethereal-dev] Mission to ASN.1 ethereal dissector
generator




> -----Original Message-----
> From: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Chris Waters
> Sent: venerd� 26 settembre 2003 0.36
> To: john.bourke@xxxxxxxxxxxxxxxxxx; ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] Mission to ASN.1 ethereal dissector
> generator
>
>
> Hi,
>
> On the topic of dissector generators. I have been playing with a plugin
> which loads a text file at runtime and generates a dissector. The
> idea is to
> make it easy to prototype new protocols, and add new dissectors for simple
> protocols.
>
> I looked at the XML protocol specification being used by Analyzer
> 3, but it
> is way to complicated for what I needed. I don't aim to replace the C
> dissectors for complex protocols and so all of the options are
> unnecessary.

I would like to point out that a shared format is an advantage for both
Ethereal and Analyzer.
I said in several occations that we're very happy to modify our
implementation if there are better proposal and new fresh programmers.

Nobody says that you have to use all the XML tags. A carefully designed
parser MUST be able to pick some standard value for the attributes that are
not specified.
It seems to me that we're going to duplicate lot of efforts, which is a pity
(expecially because none of us is paid in doing this stuff).

fulvio

> I wanted a text file format that someone could use without
> needing to read a
> manual (because I don't want to have to write a manual :-).
>
> Here is an example protocol specification. This is for the winpcap remote
> capture protocol.
>
> -------------------------------------- rpcap.proto
> protocol {
>     name "Remote Capture Protocol",
>     short "RPCAP",
>     abbrev "rpcap",
>     follows {"tcp.port", 2002}
> }
>
> option commands {
>     1 = "Error",
>     2 = "List all devices request",
>     3 = "Open adapter request",
>     4 = "Start capture request",
>     5 = "Update capture filter request",
>     6 = "Close adapter",
>     7 = "Packet transfer",
>     8 = "Authentication request",
>     9 = "Get stats request",
>     10 = "End capture request",
>
>     130 = "List all devices reply",
>     131 = "Open adapter reply",
>     132 = "Start capture reply",
>     133 = "Update capture filter reply",
>     136 = "Authentication reply",
>     137 = "Get stats reply",
>     138 = "End capture reply"
> }
>
> field {name "Version", abbrev "version", desc "", type FT_UINT32, radix
> BASE_DEC}
> field {name "Command Type", abbrev "command", desc "", options commands,
> type FT_UINT32, radix BASE_DEC}
> field {name "Value", abbrev "value", desc "", type FT_UINT16, radix
> BASE_DEC}
> field {name "Length", abbrev "length", desc "", type FT_UINT32, radix
> BASE_DEC}
>
> #column_info {command}
>
> switch rpcap.command {
> case 4:
>     field {name "Snapshot Length", abbrev "snaplen", desc "", type
> FT_UINT32, radix BASE_DEC}
>     field {name "Read Timeout", abbrev "timeout", desc "", type FT_UINT32,
> radix BASE_DEC}
>     field {name "Snapshot Length", abbrev "flags", desc "", type
> FT_UINT16,
> radix BASE_DEC}
>     field {name "Port Data", abbrev "port", desc "", type FT_UINT16, radix
> BASE_DEC}
>
>     # Filter
>     field {name "Filter Type", abbrev "filtertype", desc "", type
> FT_UINT16,
> radix BASE_DEC}
>     field {name "Dummy", abbrev "dummy", desc "", type FT_UINT16, radix
> BASE_DEC}
>     field {name "Number of Items", abbrev "numitems", desc "", type
> FT_UINT32, radix BASE_DEC}
>     break
>
> case 137:
>     field {name "Packets received by kernel filter", abbrev "ifrecv", type
> FT_UINT32, radix BASE_DEC}
>     field {name "Packets dropped by the network interface",
> abbrev "ifdrop",
> type FT_UINT32, radix BASE_DEC}
>     field {name "Packets dropped by kernel filter", abbrev
> "krnldrop", type
> FT_UINT32, radix BASE_DEC}
>     field {name "Packets sent to the RPCAP collector", abbrev "srvcapt",
> type FT_UINT32, radix BASE_DEC}
>     break
>
> default:
>     field {name "Payload", abbrev "payload", type FT_BYTES, radix
> BASE_HEX}
>     break
> }
> --------------------------------
>
> When Ethereal starts this file is loaded by the plugin and a dissector is
> registered for it. The dissector works by traversing a tree and
> slicing the
> packet based on the fields which are seen. There is still a lot of work to
> be done to allow repeating fields and encapsulation of other
> protocols, but
> even at this level I think the plugin is useful.
>
> Regards,
>
> Chris.
>
> ----- Original Message -----
> From: "John Bourke" <john.bourke@xxxxxxxxxxxxxxxxxx>
> To: <ethereal-dev@xxxxxxxxxxxx>
> Sent: Thursday, September 25, 2003 3:22 PM
> Subject: [Ethereal-dev] Mission to ASN.1 ethereal dissector generator
>
>
> >
> > Folks,
> >
> > Myself and some others have some time now to knock this ASN.1->Dissector
> on
> > the head.  We need to get it finished by November.
> >
> > So far I can see three options
> >
> > 1. Gerald's Python work
> > 2. III-ASN-Parser
> > 3. SNACC (the recent one)
> >
> > I'd like to specifically produce a Dissector generator, rather than a C
> code
> > generator.  Also I'd like to be able to register display filters against
> > parts of the code.
> >
> > Does anyone have a strong opinion ?
> >
> > Thanks
> >
> > john
> >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev



_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev