Ethereal-dev: Re: [ethereal-dev] Clear warnings patch.
> Well, I am not sure, what are the reasons against dependency on external
> library,
Well, there've been some problems with SNMP libraries in particular:
1) at least one SNMP library Tim Ramsey linked with on Solaris
2.6 included code to fetch information from the kernel, *and
did so in routines called by Ethereal*, the fact that we're
just decoding SNMP packets nonwithstanding - this obliged him
to link with "-lkstat" (hopefully, the code paths that called
"-lkstat" routines weren't used in Ethereal if "/dev/kstat",
or whatever it's name is, doesn't have public read access);
2) it requires that you have an SNMP library installed in order
to be able to dissect SNMP packets - I can see requiring an
SNMP library, or SNMP software of some sort, in order to have
an SNMP agent running on your machine, or to query SNMP
agents from your machine, but you may want to be able to
dissect captures of conversations between *other* machines
even if you don't have any need to run SNMP software on your
machine;
3) SNMP isn't the only protocols using ASN.1 that we might want
Ethereal to dissect (I think LDAP uses it as well, for
example);
4) having to cope with the presence or absence of two different
flavors of SNMP routines somewhat clutters the SNMP
dissection code and the configure script and "Makefile.am";
5) I'm not sure any existing SNMP libraries support the
DISPLAY-HINT clause of the TEXTUAL-CONVENTION macro, and
that'd be somewhat nice to use when displaying variables;
6) we've had other annoying configuraton problems with SNMP
libraries, e.g., for some reason, the version Randall Hopper
was running on his IRIX system required that the "__P()"
macro be defined (it was using it in "asn1.h" - the 4.0.1
version of UCD SNMP doesn't use it; I don't know what version
he had);
7) not all SNMP libraries can cope with 64-bit data types - I
just found out that GLib checks whether your compiler
supports "long long", and defines "gint64"/"guint64" if it
does (I think most if not all UNIX compilers that support
64-bit integral data types use "long long {int, unsigned
int}" for it - even on 64-bit platforms, "long long" is 64
bits, rather than being 128 bits, i.e. twice a "long" -
although I think it's "__int64" or something like that in
Visual C++ on Windows) - and it'd be nice to be able to
handle that even if whatever SNMP library you have on your
machine doesn't;
8) the SNMP libraries also might return errors for malformed
packets in places where it might be possible for us to
indicate in some detail the problem with the packet and to
continue dissection, which might be useful if Ethereal is
being used to debug the code that's generating the malformed
packets.
I guess I'm loath to use external libraries to do packet dissection
work, as that removes some of the work of dissection from our control -
we depend on what the library in question can do.
SNACC *might* also be adaptable into something that takes an ASN.1
description of a packet's syntax and emits an Ethereal dissector,
although I'm not sure yet whether it'd allow us to give the dissector
*semantic* knowledge (e.g., knowing that a particular field should be
displayed with "val_to_str()", and to specify the value-to-string
mapping table) - that's a potential problem with stuff that generates
dissectors from packet syntax descriptions, e.g. something to take Sun's
XDR/RPC description language, as accepted by "rpcgen", or Richard's
stuff to parse SMB descriptions.
