Template:FAQ:Coding 14

There are probably four main reasons why a new MIB module isn't working. Either it hasn't been included in the running agent, the code is present but hasn't been initialised, the module has been initialised but the handler isn't being called, or there's a problem with the module code itself.

To check whether the code files are being compiled, the easiest approach is simply to look at the directory where the code is located. When the agent is compiled, this should produce .o files (and probably .lo files) corresponding to the C code files for this module. Alternatively, run nm (or strings) on the MIB module library (libnetsnmpmibs), and look for the names of the initialisation routines or handlers (or the text of any messages displayed by the module code).

One other thing to check is whether you have multiple copies of the software installed on the system. This is a particular problem when compiling from source (to include your new module), without first removing any vendor-supplied version of the agent (which won't include this new code).

Assuming that you have confirmed that the module code is present in the agent, the next step is to check whether the initialisation routine is being called to register the MIB objects. The simplest way to do this is to include a suitable debugging statement within the initialisation routine, and start the agent with the corresponding '-Dtoken'. Alternatively, try walking the nsModuleName column object, and look for mention of the new MIB module.

Assuming the module has been registered, the next step is to check whether the handler is being called, when the agent receives a suitable SNMP request. Again, the simplest way to do this is to include debugging statements within the handler routine, and start the agent with the corresponding '-Dtoken'. Then issue an snmpget request for an instance within the new MIB module. (This command is preferable to the usual snmpwalk command, as it is more closely focused on the MIB module in question).

If this indicates that the handler routine isn't being called, then there are two main likely causes. Firstly, check the access control settings. If these are configured to block access to this portion of the OID tree, then the MIB handler will never be called. Secondly, several of the table helpers are designed to know which rows of the table are valid, and will call the main MIB handler with information about the relevant row. If the requested row is not valid (or the table is empty), then the handler will not be called.

Finally, if the handler is being called, but is still not returning any information, then the cause probably lies with your MIB module code. In which case, it's really up to you to find the problem and fix it! Either activate any debugging code that you have included within the handler routine, or run the agent under a source code debugger, and step through the handler processing. In either case, it's much easier to debug these problems when processing an snmpget request, rather than snmpgetnext or snmpwalk.

Remember that mib2c simply generates template code for your MIB module. It's up to you to fill in the details, to report the actual information from whatever underlying subsystem is being monitored. Mib2c cannot help with the semantics of the MIB module - it's purely there to provide an initial code framework, based on the syntax of the MIB module objects.