Libsmi June 1999

libsmi@ibr.cs.tu-bs.de

2 participants
10 discussions

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

libsmi maintainance release 0.1.2
by Frank Strauss 03 Jun '99

03 Jun '99

Hi! Jochen Friedrich reported a bug with modules specified by pathname to smiLoadModule(). This has been fixed. smiGetPath() and smiSetPath() are now implemented. A few string length restrictions have been eleminated and an obsolete header file has gone. 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

Re: [libsmi] smiLoadModule and smiInit
by Frank Strauss 03 Jun '99

03 Jun '99

Hi! Jochen> we try to use libsmi in future versions of GxSNMP and replace Jochen> the ancient related functions from CMU. Things look pretty Jochen> good so far :). Fine. ;-) Jochen> We want to have the possibility to configure which MIBs get Jochen> loaded by GxSNMP during startup. Is this the management application project within the GNOME framework? Jochen> One problem is that there is no way to override the compiled Jochen> in search path other than setting an environment variable Jochen> (GxSNMP might fork() from plugins and exec other programs whch Jochen> might be f'd by a changed SMIPATH). Would it be possible to Jochen> add a parameter to smiInit() to override the search path? The smi.h File already contains two function declarations extern int smiGetPath(const char *path); extern int smiSetPath(const char *path); (with wrong signatures ;-)) that are intended to allow an application to adjust the search path. Expect the implementation of these two functions to be implemented in the next release (probably, today or tomorrow). Jochen> Another problem is that smiLoadModule always returns -1 when a Jochen> full path to a module is specified. The problem seems to be Jochen> that the path is not chopped off before verifying if the Jochen> module with the given name really has been loaded. I'll check this... Jochen> Last not least (for our MIB browser), is there an easy way to Jochen> walk though all nodes of the tree without using the data.h Jochen> internal header file? Yes. BTW, an application shall never use the knowledge of data.h. It is not part of the API. To get an understanding of how to retrieve definitions in a get-first/get-next style, please take a look at tools/dump-sming.c (or tools/dump-smi.c): static void printObjects(char *modulename) { [...] SmiNode *smiNode; for(smiNode = smiGetFirstNode(modulename, SMI_DECL_UNKNOWN); smiNode; smiNode = smiGetNextNode(smiNode, SMI_DECL_UNKNOWN)) { [...] } } Note that this way to iterate through the node definitions of a module guaranties to retrieve the nodes in depth first order, not in the order they are defined in the module. This is convienent for most uses (like MIB browsers ;-)) and eliminates forward references where possible. With the second argument set to SMI_DECL_UNKNOWN, you'll retrieve any node definitions. You might also want to retrieve only a certain kind of nodes, e.g. notification types, by setting this to the appropriate value. 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

smiLoadModule and smiInit
by Jochen Friedrich 03 Jun '99

03 Jun '99

Hi, we try to use libsmi in future versions of GxSNMP and replace the ancient related functions from CMU. Things look pretty good so far :). We want to have the possibility to configure which MIBs get loaded by GxSNMP during startup. One problem is that there is no way to override the compiled in search path other than setting an environment variable (GxSNMP might fork() from plugins and exec other programs whch might be f'd by a changed SMIPATH). Would it be possible to add a parameter to smiInit() to override the search path? Another problem is that smiLoadModule always returns -1 when a full path to a module is specified. The problem seems to be that the path is not chopped off before verifying if the module with the given name really has been loaded. Last not least (for our MIB browser), is there an easy way to walk though all nodes of the tree without using the data.h internal header file? Thanks, Jochen -- !! 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 bugfix release 0.1.1
by Frank Strauss 02 Jun '99

02 Jun '99

Hi! At least on the Linux platform a bug in the code that searches for MIB module files, has lead to segmentation faults, when the SMIPATH environment variable has not been set. This bug has been fixed. Furthermore, configure.in has a new option: --with-smipath="DIR:DIR:..." can be used to specify a default path, if the user has no SMIPATH set, e.g. if you have scotty installed along with its MIB modules, you might want to configure libsmi like this: ./configure --with-smipath="/usr/local/share/mibs:/usr/lib/tnm3.0.0/mibs" 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/~strauss/libsmi/ for more information.

1 0

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 June 1999