- Libsmi - lists.ibr.cs.tu-bs.de

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

libsmi release 0.1.6
by Frank Strauss 23 Jun '99

23 Jun '99

Hi! I've just compiled a new libsmi release and put it on ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/ It fixes some bugs, mainly a nasty one with definitions of the same node read from different modules, reported by Jochen Friedrich. A major new feature is the SMIv1 output format of smidump, contributed by Juergen Schoenwaelder. Some more checks have been added to the SMIv1/v2 parser, mainly for imported identifiers. Meanwhile, I've started to use smilint to check a whole bunch of IETF Standards Track and I-D MIB modules. I'll collect the results at the `MIB modules bug hitlist': http://www.ibr.cs.tu-bs.de/projects/libsmi/mibs.html Frank PS: Due to the migration of our FTP archive to a new machine, you might have missed some files in the archive for some past hours. -- !! 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: core dump with 0.1.5
by Frank Strauss 21 Jun '99

21 Jun '99

Jochen Friedrich <jochen(a)scram.de> writes: > it looks like some nodes may get corrupted if multiple SMI files are > loaded. [...] Hopefully, libsmi-0.1.6-pre2, that I'm just putting to the FTP archive, fixes this bug (and adds some more checkings of imported identifiers). -- !! 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] core dump with 0.1.5
by Frank Strauss 21 Jun '99

21 Jun '99

Jochen Friedrich <jochen(a)scram.de> writes: > it looks like some nodes may get corrupted if multiple SMI files are > loaded. This example dumps core for me: > [...] > smiLoadModule("RFC1213-MIB"); > [...] > /* This call crashes with a nice little core :) */ > node = smiGetNode("ifAdminStatus", NULL); > [...] This seems to be exactly that bug, I've also found last friday. ;-) I think I've tracked down to the real cause. It happens when an an access to a node takes place, that is defined in multiple modules (here RFC1213-MIB, and RFC1158-MIB, which is imported by RFC-1212, which in turn is imported by RFC1213-MIB). Subtrees are stored below a `pending' tree as long as their parent is unknown due to forward references that are allowed in SMIv1/v2. When the parent gets defined the subtree gets moved to the main node tree. But this is incorrect: it must be *merged into* the main tree, because another module may have defined these nodes already. Hence, pointers from Objects of previously loaded modules to a node get invalid. I have to build a recursive tree merge function in data.c paying attention to some pointer adjustments. I hope to fix this problem today or tomorrow. -- !! 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

libsmi release 0.1.5
by Frank Strauss 21 Jun '99

21 Jun '99

Hi! libsmi 0.1.5 has just been released. Besides a few bugfixes it contains some tests that can be used to check the library and the tools if you have SNMPv2-MIB, IF-MIB, MAU-MIB, RMON2-MIB, and all dependant MIB modules installed. Some API structs and functions have been revised to increase efficiency, namely OIDs are now represented by int[] instead of a string, and some more knowledge on the underlying MIB language gets hidden from applications. As usual, information on the libary and the actual code may be found at http://www.ibr.cs.tu-bs.de/projects/libsmi/ ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/ 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

libsmi release 0.1.4
by Frank Strauss 10 Jun '99

10 Jun '99

Hi! ``Release early, Release often!'' [The Cathedral and the Bazaar, Eric S. Raymond.] Some ugly bugs have been fixed, compile time warning should have been gone, and smidump is able to dump in SMIv2 format, again. Some checks may be run by `make check', if you have some standard MIBs on board. As usual, the code is placed at http://www.ibr.cs.tu-bs.de/projects/libsmi/ ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/ Have fun! 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.

1 0

libsmi release 0.1.3
by Frank Strauss 08 Jun '99

08 Jun '99

Hi! I've just released libsmi 0.1.3. It fixes a number of (mostly SMIng related) bugs. The API changed slightly: A new structure for table index information was required. Juergen Schoenwaelder submitted a patch for smidump that makes it dump MIB information in MOSY style output. Another simple dump format allows to show module import hierarchies. Finally, the parsers are able to read RMON2-MIB again. ;-) As usual, the code may be found at http://www.ibr.cs.tu-bs.de/projects/libsmi/ ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/ 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.

1 0