Jochen Friedrich <jochen(a)scram.de> writes:
> However, i have a different (feature enhancement?) question. In GxSNMP,
> i'm currently drawing a GUI tree object for visually browing through the
> MIB. Here, i have the problem to connect each GUI leaf object with the SMI
> node it represents. Before OID was switched to the int[]/length pair, i
> just used the OID as handle representing the node. After the change,
> libsmi no longer provides some kind of handle to identify a node in a
> unique way. Would it be possible to add a handle to the node
> structure which can later be used to retrieve the node out of libsmi
> again?
Probably, I did not get your problem right. Anyway:
You can still use an OID string to retrieve node definitions by smiGetNode().
You should note, that an OID (either as int[] or char*) does only
identify a node of the OID tree uniquely (which is nothing more, than
the OID itself). It does not identify a struct SmiNode unambiguously,
since it can be defined in multiple versions of the same module, or with
non-registering definitions in multiple modules (e.g. the mib-2 node?)
(see my recent answer to Diego's question).
Hence, if you wish to keep stuck with a definition you retrieved once,
you should remember the module and name of that definition.
[Even a module name might be used for multiple modules, so that a module
should be unambiguously identified by an OID. But this is not implemented
in libsmi, and seems to keep theory.]
--
!! 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(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
> 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(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
>>>>> Diego Parrilla writes:
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.
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.
Juergen
--
Juergen Schoenwaelder schoenw(a)ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289)
--
!! 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(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi, I'm wrapping the smilib library for C++ development, but I can`t
retrieve Description and Reference information from any node. I don´t
know if it's my fault or this feature is not yet implemented. ¿ Can
anybody help me ?
Yours
Diego Parrilla
Hi!
[Your message to the libsmi list has been bounce, because you're not
subscribed to the list. Anyway.]
Bismarck> Date: Wed, 07 Jul 1999 10:16:13 -0400
Bismarck> From: Bismarck Leung <sftwr(a)silcomtech.com>
Bismarck> To: libsmi(a)ibr.cs.tu-bs.de
Bismarck> Subject: Does anyone have the Windows version of the libsmi ?
Bismarck> Or anything similar to it.
Bismarck> Please let me know if you do.
Juergen Schoenwaelder [Cc] compiled a very early version of libsmi on
a Win32/Cygnus environment. There were just very slight problems with
a header to be included for getopt() and the 64bit strtoll()
function(s), AFAIK.
I have no access (and no primary intention) to support Win32. Anyway,
if you can supply concrete patches I'll integrate them.
Frank
--
!! 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(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
