Ethereal-dev: Re: [ethereal-dev] packet-snmp.c and libsmi

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 23 Jun 2000 10:43:08 -0700 (PDT)
> When adding SNMPv3 and SMUX to ethereal, i also patched it up to use
> libsmi instead of UCD SNMP. However, there have been 2 yet unresolved
> concerns (quoting Guy Harris):

In case he hadn't seen the messages in question, some additional
context:

> 1. (this was due to the API change between libsmi 0.1 and 0.2):
> 
> Is the API (and the ABI!) likely to change in an incompatible fashion in
> a future release?  If so, that could cause this problem to show up
> again.

"This problem" refers to a problem introduced by a (probably
inadvertent) change to the ABI of the UCD SNMP library between 4.1 and
4.1.1 - RPMs of Ethereal built on RH 6.1, which came with some pre-4.1.1
version of UCD SNMP, didn't work on RH 6.2, as they failed to find a
particular library routine in the shared UCD SNMP library with which
they were linked (the routine had been turned into a macro).

I'd prefer not to require people to use libsmi 0.x, and not be able to
use libsmi 0.y for y > x, to run Ethereal; requiring them to run *at
least* libsmi 0.x would probably be OK, as long as there isn't some
Linux distribution release/*BSD release out there on a lot of machines
that comes only with libsmi 0.z for z < x (i.e., I'd prefer not to
require lots of people to upgrade their libsmi in order to use, say, a
pre-package RPM of Ethereal, although I'd oppose that less than I'd
oppose them having to *downgrade* their libsmi).

> 2. 
> 
> ...except that it takes significantly *more* time with libsmi than with
> UCD SNMP; perhaps that's just because there are fewer MIBs that come
> with UCD SNMP, but, on my 450 MHz PII/128MB memory machine, it takes
> several seconds longer for an Ethereal linked against libsmi to start up
> than it takes for an Ethereal linked against UCD SNMP to start up (even
> after all the pages of the executable and the MIB files are cached in
> memory after having run both programs once).

I don't know whether any performance work has been done on the
MIB-reading code; I haven't yet done a profiled run of Ethereal (or
Tethereal) linked with libsmi to see if there's any low-hanging fruit.