Hi Ahmad,
On Sat, Jan 28, 2017 at 08:04:11PM +0100, Ahmad Fatoum wrote:
> Hello everyone,
>
> As part of a school project, we intend to extend the Ethernet POWERLINK
> (packet-epl.c) dissector in Wireshark to be able to read in the XML device
> description files (XDD) and use that information to dissect the packet
> payload (The data field is currently displayed as a byte stream).
>
> As we would like to have the changes eventually merged into the trunk, we
> want to check what XML library we should use?
>
> We are hesitant to rely on GMarkup, because we don't control the input, and
> don't want to later find out that it doesn't manage some more complex
> device profiles. Wireshark depends on lex(1), but I wouldn't want to
> reinvent the wheel and rather use some out-of-the-box parser.
>
> So what's the stance on dissectors pulling in dependencies like libxml? Any
> other suggestions?
Some (family of) dissectors are generated from description files (ASN.1,
PIDL, ...). These "compilers" are Python/Perl/... programs which
sometimes have additional dependencies at the time of generation, but
are otherwise just normal C dissectors without additional dependencies
after generation.
Would this method of generating a dissector help? You can find some
examples in epan/dissectors/asn1/, epan/dissectors/pidl/,
epan/dissectors/README.X11.
If the XML files describing the payload vary at runtime, I do not have a
particular suggestion for an approach.
> With kind regards
> Ahmad Fatoum
>
> ps: Out of curiosity, is there a particular reason e.g. PROFINET is a
> plugin while Ethernet POWERLINK is statically linked?
Most dissectors are located in epan/dissectors/ (statically linked). I
guess someone started with the PROFINET dissector as plugin and it just
continued living there.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
