On Tue, Feb 26, 2002 at 10:32:18PM -0600, Gilbert Ramirez wrote:
> Perhaps the default "configure" action should be --disable-snmp
> until this is fixed. It's drastic, but safer.
That might not be a bad idea for the short-term workaround.
NET-SNMP 5.0-pre1 has "sprint_realloc" routines that look as if they
*might* fix this problem, if, as I infer, they format into a string
buffer that grows dynamically.
Unfortunately, the MIB_API(3) man page in the 5.0-pre1 release hasn't
been update to document those routines (in fact, they only mention the
non-reallocating "sprint" routines in passing, and don't mention them in
the synopsis), so I'd have to dig into the code further to make sure
they do what I suspect they do.
libsmi might also let us do "safe" formatting of OIDs and variable
bindings.
I'd be inclined either to
1) switch to libsmi
or
2) require NET-SNMP 5.0 once it's released (and not support CMU
SNMP, unless *it* has a safe formatting API that I've missed,
or earlier UCD SNMP/NET-SNMP releases), and use the new APIs,
if they do what I suspect they do.
Either of those would let us get rid of the stuff in "packet-snmp" that
deals with:
1) allowing Ethereal to use either with UCD SNMP/NET-SNMP or CMU
SNMP;
2) UCD SNMP 4.1.1 binary-incompatibility problem;
3) the source compatibility problem caused by the incompatible
modified formatting API in the UCD SNMP in some versions of
some Linux distributions.
Switching to libsmi might also let us get rid of the problems with Red
Hat binary packages and libcrypto, as I don't think libsmi uses
libcrypto. However, I think you have to have a configuration file to
tell libsmi which MIBs to load - the SNMP libraries don't need that -
and, when I last looked at it a while ago, it took significantly longer
to load MIBs than did UCD SNMP. (And if we require NET-SNMP 5.0,
perhaps all RPMs for it will at least have the *same* dependencies,
etc., so that, *if* the problem people have been seeing is due to
differences between the SNMP package with which the Ethereal binaries
are built and on which the Ethereal RPMs depend and the latest shiniest
SNMP RPMs, those problems might go away as you'd have to build the
Ethereal RPMs with recent SNMP RPMs.)
