Interesting,
is this work similar to the proposal/idea i described a few months ago?
I.e. making the signatures and structures for all helpers and
dissection tables that asn2eth generates encoding rule agnostic and
use a function pointer structure
struct ans_function_pointers {
int (*dissec_asn_integer(...
...
that can be passed in through a pinfo-> field or something?
Then changing all packet-ber and packet-per helpers use the new
signatures and the pinfo-> function pointer struct.
This would make asn2eth completely encoding method agnostic and for
example it would allow us to have
1 single dissector autogenerated by asn2eth that could dissect both
the BER and the text encoding for MEGACO/H.248.
The filter fields would even be the same between the two encodings.
There would just be two different entry points one that would set
the pinfo-> pointer to the BER helpers and another that would set it
to point to the (to be written) text encoding struct.
It would also make it possible to implement full RDP/T.120 support
that would automatically handle both the PER and the legacy encoding.
We would just need to create the helpers for the legacy encoding functions.
On 4/27/05, Tomas Kukosa <tomas.kukosa@xxxxxxxxxxx> wrote:
> Hi Herbert,
> I am making extensive changes in ASN2ETH now and I can add another
> encoding (BACnetER) too.
> Please, do not make big change in ASN2ETH now, it would be problem to merge
> our changes.
>
> What is planned protocol name for BACnetER helper? ("bacneter", "bner",
> ...)
> Will be BACnetER helper API compatible e.g. with current BER or PER API?
>
> Regards,
> Tom
>
> Herbert Lischka wrote:
> > Hi Ronnie,
> >
> > I found this german Diplomarbeit at
> > http://www.abmlinux.de/DA/Diplomarbeit.pdf
> > and it seems interesting for me to study it and to try the
> > reimplementation, but in this Diplomarbeit they write about at least 3
> > months of work.... so
> > "What we need is to make ASN2ETH encoding agnostic ... and make it
> > easy to implement and add new encodings for asn1 defined protocols."
> > I will try it.
> > If I need some help, may I ask you ?
> >
> > Best regards
> > Herbert
> >
> > ronnie sahlberg wrote:
> >
> >> I very rarely compile for windows,
> >> I see you add a new library ICONV.LIB to the makefile and i assume
> >> to the dependencies.
> >>
> >> Is this a library available on all windows boxens ?
> >
> > libiconv is already used if you compile with GTK2
> >
> >> I notice there is a libiconv package required for windows, is this
> >> this library referenced from the Makefile.nmake?
> >
> > It's the same
> >
> >>
> >> I dont really like that this dissector tries to implement its own
> >> handwritten BER unmarshalling. There is already a too many of these
> >> reimplementations of BER decoding helper functions in ethereal and we
> >> should not add more. The ones we do have in packet-ber.c are the only
> >> ones which are reasonably well tested, works reasonably well and are
> >> used by teh automatic asn.1 to ethereal compiler.
> >>
> >>
> >>
> >> It seems bacapp is really just a protocol described by asn.1 and using
> >> BER for encoding.
> >
> > most of the dissectors I added described by asn.1 in my headerfile
> >
> >> Instead of adding to this one what really should be done is to
> >> reimplement BACapp from scratch as a dissector generated automatically
> >> from the ASN.1 definitions and using ASN2ETH.
> >>
> >>
> >> Is the BACAPP ASN.1 protocol specification publicly available?
> >
> > at http://www.ashrae.org -> bookstore
> > "Standard 135-2004 – BACnet(r) – A Data Communication Protocol for
> > Building Automation and Control Networks (ANSI Approved)"
> > price $119,--
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
