["Chris Waters" <chris@xxxxxxxxxxxx>]

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 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
>