How to list SMIv1 MIBS with net-snmp MIB API in C/C++?

Question

I want to display a list of various MIBS with net-snmp and show other informations related to the SNMP tree structure.

Now it turns out that my customer's SMIv1 MIBS does not show up in the listing, but are correctly loaded by net-snmp.

Sample net-snmp code goes through the MIB structure in memory and assumes that we have the SMIv2 bijection between a MIB and a MODULE-IDENTITY note in the tree. So when we find a MODULE-IDENTITY node, we find a MIB.

Does anybody knows what is the correct method to list SMIv1 MIBS with net-snmp ? (or any workaround ?)

  // Read mibs and obtain memory structures
  struct tree * head = read_all_mibs();
  // Walk down the SNMP tree
  for ( struct tree * tp = head; tp; tp = tp->next_peer )
  {
     // Module-indentity
     if ( tp->type == TYPE_MODID )
     {
        // XXX We found a SMIv2 MIB, but SMIv1 MIBs have no MODULE-IDENTITY node
     }
  }

NB: I found a converter smidump (a command line tool, or as a web service at http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) but it does not adds a MODULE-IDENTITY node to the MIB.

Edit: Note that any tool that would convert an old SNMP MIB to a more recent one (SMIv2 style), could solve the problem. Any help in that particular direction ?

One suggestion could be, in the absence of MODULE-IDENTIFIER, to find the root OBJECT-IDENTIFIER of the MIB (sometimes the MIB will add node at many different and unrelated places so this would not work). With a root node I could show most of the tree related to that MIB.

Answer 1

The only solutions my colleague and I found to fix the problem, was to convert the "top-level" MIB(s) into a more SNMPv2-like structure. That is 1) import the type MODULE-IDENTITY, 2) replace the top-level node with a MODULE-IDENTITY declaration.

    ...
    IMPORTS
       MODULE-IDENTITY
       FROM
       SNMPv2-SMI
    ...

    -- Removed top-level node
    --    compaq              OBJECT IDENTIFIER ::= { enterprises 232 }

    -- Add a fake module-identity node
    compaq MODULE-IDENTITY
    LAST-UPDATED   "200111120000Z"
    ORGANIZATION   "COMPAQ"
    CONTACT-INFO
           "why.still.using.snmpv1@compaq.com"
    DESCRIPTION
           "why does compaq still provide these mibs in 2013?"
    REVISION       "9407210000Z"
    DESCRIPTION
           "Normal fixed MIB module."
    ::= { enterprises 232 }

With this fix, the net-snmp library will show us a module-identity node for our MIB, just like with every other SNMPv2 mibs..

Answer 2

It uses UDP datagrams. You can get sources of net-snmp or snif UDP traffic (looks like an easier way).

Answer 3

net-snmp is an agent (i.e. server) running snmp on device. What client (i.e. mib browser or command line tool such as snmp-get/walk etc.) are you using to query that? Is your client also loaded with the same MIB as server?

I presume you are using SNMPv1. Are you using the correct access community i.e. you are typing the correct password from client (MIB browser or command line snmp client) to autheticate with the SNMP Agent / server?

I suggest using a GUI based client (called SNMP Manager) for locating the problem. Such asMGSOftMIBBrowser

The trial version is free. And you see results of attempts such as failed password (community name for snmpv1).

Among several other possible problems could be:

SMIv1 is an old format. So you need to ensure the version of net-snmp you are using supports it.

If you are using SNMPv2, it is possible that you are authenticating with correct community. However, your community does not have read access for the mib you wish to see. SNMPv2 introduced concept of views in which you can allow a certain subset of oid tree to be visible to a particular community (user).

If it is a non standard mib, (i.e. not part of core snmp mibs), you should find it's complete OID (something like 1.3.4.1.2...) and first check in the GUI (MIB browser) if it exists or otherwise debug get request against the specific oid.

Also understand that a non standard mib needs to be loaded in both agent as well as client. Otherwise client won't know the details of a mib to be able to query requests on it's behalf.