4 The MIB Compiler

This section describes the MIB compiler and contains the following topics:

• Operation
• Import
• Consistency checking between MIBs
• .hrl file generation
• Emacs integration
• Deviations from the standard

4.1 Operation

The MIB must be written as a text file in ASN.1 before being compiled. This text file must have the same name as the MIB, but with the suffix .mib. This is necessary for handling the IMPORT statement.

The association file which contains the names of instrumentation functions for the MIB should have the suffix .funcs. If the compiler does not find the association file, it gives a warning message and uses default instrumentation functions. (See see Default Instrumentation for more details).

The MIB compiler is started with a call to snmp:c(<mibname>). For example:

snmp:c("RFC1213-MIB").
    

The output is a new file which is called <mibname>.bin.

The MIB compiler understands both SNMPv1 and SNMPv2 MIBs. It uses the MODULE-IDENTITY statement to determinte if the MIB is version 1 or 2.

4.2 Importing MIBs

The compiler handles the IMPORT statement. It is the compiled file which is imported, not the ASN.1 file. Therefore, an MIB must be recompiled to make changes visible to other MIBs which import it.

The compiled files of the imported MIBs must be present in the current directory, or a directory in the current path. The path is supplied with the {i, Path} option, for example:

snmp:c("MY-MIB", 
       [{i, ["friend_mibs/", "../standard_mibs/"]}]).
    

It is also possible to import MIBs from OTP applications in an "include_lib" like fashion with the il option. Example:

snmp:c("MY-MIB", 
       [{il, ["snmp/priv/mibs/", "myapp/priv/mibs/"]}]).
    

finds the lastest version of the snmp and myapp applications in the OTP system and uses the expanded paths as include paths.

Note that a SNMPv2 MIB can import an SNMPv1 MIB and vice versa.

4.3 MIB Consistency Checking

When an MIB is compiled, the compiler detects if several managed objects use the same OBJECT IDENTIFIER. If this is the case, it issues an error message. However, the compiler cannot detect Oid conflicts between different MIBs. These kind of conflicts generate an error at load time. To avoid this, the following function can be used to do consistency checking between MIBs:

erl>snmp:is_consistent(ListOfMibNames).
    

ListOfMibNames is a list of compiled MIBs, for example ["RFC1213-MIB", "MY-MIB"]. This function also performs consistency checking on trap definitions.

4.4 .hrl File Generation

It is possible to generate an .hrl file which contains definitions of Erlang constants from a compiled MIB file. This file can then be included in Erlang source code. The file will contain constants for:

• object Identifiers for tables, table entries and variables
• column numbers
• enumerated values
• default values for variables and table columns.

Use the following command to generate a .hrl file from an MIB:

erl>snmp:mib_to_hrl(MibName).
    

4.5 Emacs Integration

With the Emacs editor, the next-error (C-X `) function can be used indicate where a compilation error occurred, provided the error message is described by a line number.

Use M-x compile to compile an MIB from inside Emacs, and enter:

 erl -s snmp c <MibName> -noshell
    

An example of <MibName> is RFC1213-MIB.

4.6 Compiling from a shell or a Makefile

The erlc commands can be used to compile SNMP MIBs. Example:

 erlc MY-MIB.mib
    

4.7 Deviations from the standard

In some aspects the Erlang MIB compiler doesn't follow or implement SNMP fully. Here are the differences:

• The compiler doesn't allow forward references.
• Tables must be written in the following order: tableObject, entryObject, column1, ..., columnN (in order).
• Bit string values on the format '10100011'B are not implemented. Use hex or ASCII string syntax instead.
• Integer values, for example in the SIZE expression must be entered in decimal syntax, not in hex or bit syntax.
• Symbolic names must be unique within a MIB and within a system.
• Types cannot be redefined.
• Hyphens are allowed in SNMPv2 (a pragmatic approach).
• If a word is a keyword in any of SNMPv1 or SNMPv2, it is a keyword in the compiler.
• Indexes in a table must be objects, not types.
• A subset of all semantic checks on types are implemented. For example, strictly the TimeTicks may not be sub-classed but the compiler allows this (standard MIBs must pass through the compiler).
• The MIB.Object syntax is not implemented (since all objects must be unique anyway).
• Two different names cannot define the same OBJECT IDENTIFIER.
• The type checking in the SEQUENCE construct is non-strict. (e.g. subtypes may be specified)