Diego> When I try to retrieve Description and/or Reference information Diego> from any node with the full OID (e.g.: .1.3.6.1.2.1.2.1), both Diego> fields return empty. But if I use the equivalent label of the Diego> OID ("ifNumber", I think...), these fields return the right Diego> values. I call the "smiGetNode" function for this action.

As Jochen already wrote, the correct way to write an OID is without the leading dot. I know that CMU/UCD do it differently and many people took over that style. But that does not make it legal.

Another reason might be an old version of libsmi, which had a bug in finding the right object definition of a node defined in multiple modules. When you load IF-MIB, RFC-1212 and RFC1158-MIB get also loaded due to iterative imports. You can check this with `smidump -f imports IF-MIB'.

strauss@dagoba strauss/ 521 $ smidump -f imports IF-MIB IF-MIB SNMPv2-SMI [9 identifiers] SNMPv2-TC [8 identifiers] SNMPv2-SMI [2 identifiers] SNMPv2-CONF [2 identifiers] SNMPv2-SMI [3 identifiers] SNMPv2-MIB [1 identifier] SNMPv2-SMI [7 identifiers] SNMPv2-TC [3 identifiers] SNMPv2-SMI [2 identifiers] SNMPv2-CONF [3 identifiers] SNMPv2-SMI [3 identifiers] IANAifType-MIB [1 identifier] SNMPv2-SMI [1 identifier] RFC1213-MIB [1 identifier] RFC1155-SMI [6 identifiers] RFC-1212 [1 identifier] RFC1155-SMI [1 identifier] RFC1158-MIB [1 identifier] RFC1155-SMI [7 identifiers] SNMPv2-TC [1 identifier] SNMPv2-SMI [2 identifiers]

In this situation with three definitions for the node 1.3.6.1.2.1.2.1, the smiGetNode("1.3.6.1.2.1.2.1", NULL) call has to decide, which definition shall be returned. Since version 0.1.7-pre3 libsmi tries to find a definition of an explicitly loaded module (smiLoadModule()). Only if no explicitly loaded definition is found, an implicit definition is returned. Earlier versions had a bug in distinguishing explicit and implicitly known definitions.

You can check this behaviour with the smiquery tool: Though, in the first example, we only load IF-MIB explicitly (by the preload option -p), we get the unexpected definition from RFC1158-MIB (which has no DESCRIPTION):

strauss@dagoba strauss/ 520 $ smiquery -V smiquery 0.1.7-pre2 strauss@dagoba strauss/ 519 $ smiquery -p IF-MIB node 1.3.6.1.2.1.2.1 MibNode: ifNumber Module: RFC1158-MIB OID: 1.3.6.1.2.1.2.1 Type: Integer32 Basetype: Integer32 Declaration: OBJECT-TYPE NodeKind: scalar Access: read-only Status: mandatory Description: - Reference: -

strauss@henkell strauss/ 511 $ smiquery -V smiquery 0.1.7-pre3 strauss@henkell strauss/ 512 $ smiquery -p IF-MIB node 1.3.6.1.2.1.2.1 MibNode: ifNumber Module: IF-MIB OID: 1.3.6.1.2.1.2.1 Type: Integer32 Basetype: Integer32 Declaration: OBJECT-TYPE NodeKind: scalar Access: read-only Status: current Description: The number of network interfaces (regardless of their current state) present on this system. Reference: -

So, please try 0.1.7-pre3, which has not been announced on the mailinglist but is available from the FTP archive.

Anyway, recent versions of libsmi have a special function call you should use instead of smiGetNode() in this case:

extern SmiNode *smiGetNodeByOID(unsigned int oidlen, SmiSubid oid[]);

This API function makes a lookup based on an OID and it does not care about the MIB module which actually contains the definition.

The only difference from something like smiGetNode("1.3.6.1", NULL) is (should be) the argument notation. In fact, if you already have the int-array notation in your application you should use it, since it is more efficient. -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.