ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Updates to COPS & SNMP dissectors

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 8 Sep 2003 13:46:06 -0700

On Sep 5, 2003, at 3:49 AM, kari.tiirikainen@xxxxxxxxx wrote:

I changed the preference to load all MIBs by exporting
environment variable MIBS to values ALL, so that now one
can define a colon separated list of MIB modules to be loaded.
That list is then exported to the environment variable MIBS,
unless MIBS is already set.

The MIB module list is by default the same as NET-SNMP's default
"IP-MIB:IF-MIB:TCP-MIB:UDP-MIB:SNMPv2-MIB:RFC1213-MIB:UCD-SNMP-MIB".
Since NET-SNMP parses this list in LIFO way, the most recent MIBS
than will replace the older ones are defined first.
This way one can define which MIB modules have precedence,
if two or more modules define the same MIB objects.

If one wants to load all MIBs, one can simply append ":ALL"
to the default list or replace the whole default list with
keyword "ALL".

That patch didn't apply correctly, as it wasn't a "-c" or "-u" patch, but, fortunately, it wasn't *too* wrong, so I could fix the damage by hand.

However, I changed it so that there's a routine "process_prefs()" which is called when the preferences change; it unloads the MIBs if they've been loaded (false the first time through, true all subsequent times through), exports the preference setting, and then loads the MIBs.

"mib_modules" is initialized to DEF_MIB_MODULES. The register routine sets "mib_modules" to the value of MIBS, and then registers the "mib_modules" preference, but does nothing with it - it can't do anything useful, as the preferences haven't been set yet (the preferences aren't read until all dissector register routines have been called, as, until they've all been called, not all dissector preferences are known to be registered so that they *can* be read).

The register-handoff calls "process_prefs()" as, by that time, the preferences have been read.

Note that there is no such thing as a preference that hasn't been set, i.e., by the time the preferences are read, it is *guaranteed* to be the case that "mib_modules" is set - and that'd be the case even if the register routine *didn't* give it an initial value.

That's what's currently checked in.