Libsmi July 1999

libsmi@ibr.cs.tu-bs.de

4 participants
5 discussions

Re: [libsmi] Retrieving Description
by Frank Strauss 14 Jul '99

14 Jul '99

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.

1 0

Re: [libsmi] Retrieving Description
by Frank Strauss 14 Jul '99

14 Jul '99

> 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.

1 0

Re: [libsmi] Retrieving Description
by Juergen Schoenwaelder 14 Jul '99

14 Jul '99

>>>>> 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.

1 0

Retrieving Description
by Diego Parrilla 14 Jul '99

14 Jul '99

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

3 4

Re: Does anyone have the Windows version of the libsmi ?
by Frank Strauss 07 Jul '99

07 Jul '99

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.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Libsmi July 1999