Libsmi May 2001

libsmi@ibr.cs.tu-bs.de

11 participants
10 discussions

Strange problem with certain MIB constructs
by Santarelli, Brian 28 May '01

28 May '01

Hi all, I'm currently using libsmi with Delphi/Windows (I built a DLL using GCC). I am having a strange problem with certain MIBs. When I call smiGetFirstNode(ModuleName, SMI_NODEKIND_ANY) for certain MIBs, the first node structure returned is completely empty other than the OID. The second node returned (after an smiGetNextNode) is a valid node, but is not the node expected - it is actually the 5th node that should be returned. The first OID is also strange as these MIBs are enterprise MIBs and the first OID returned is similar to the following(from example 1): 1.3.6.1.4.1.5591.1.0 where it should be: 1.3.6.1.4.1.5591.1.8.1.2 (See example 1) The problem only seems to occur where the MIB has a construct like the following from example 1: downLoad OBJECT IDENTIFIER ::= { downloadIdent 1 } transponderImage OBJECT IDENTIFIER ::= { downloadIdent 2 } Example 2 does not have these constructs and the first node is returned as expected. Any ideas? Am I doing something wrong? ===================================================== Example 1 ===================================================== SCTE-HMS-DOWNLOAD-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 TRAP-TYPE FROM RFC-1215 DisplayString FROM RFC1213-MIB scteHmsTree FROM SCTE-ROOT commonPhysAddress FROM SCTE-HMS-COMMON-MIB commonLogicalID FROM SCTE-HMS-COMMON-MIB downloadIdent FROM SCTE-HMS-ROOTS ; downLoad OBJECT IDENTIFIER ::= { downloadIdent 1 } transponderImage OBJECT IDENTIFIER ::= { downloadIdent 2 } -- * -- * **************************************** -- * Firmware Download Management Group -- * **************************************** -- * This portion of the Download MIB defines the core objects -- * used to manage the download of a firmware image or block -- * of data. -- * dlDownloadDevice OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "This object defines the device which is to have firmware downloaded. A value of 1 specifies the transponder. A value of 2 to 256 specifies TIB devices 1 to 255. Values of dlDownloadDevice greater than 256 may be used for non-TIB devices managed by the transponder. This indexing scheme is used to avoid using an index value of 0 to identify the transponder. This indexing scheme matches that of dlTransponderTable. Not all transponders support TIB based devices. There are no restrictions on the value of this object. When dlDownloadControl is set to initiate(1), an invalid value for dlDownloadImage results in the inability to set dlDownloadControl. This value for this object reverts back to 0 after the end of any download or download error. As valid indices begins at 1, this provides some added security to prevent accidental erasure. The value of this object should only be changed when dlDownloadStatus is done(6). Attempts to change object during any other state results in termination of the download in progress and an error being recorded. The actions associated with detecting an error are described by Note 4 of the download state diagram presented earlier in the document. The object value will not be cleared and the new value shall be accepted. The dlDownloadKey does not affect this object. The default value is 0. This object is volatile." ::= { downLoad 2 } ===================================================== Example 2 ===================================================== SCTE-HMS-PS-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 psIdent FROM SCTE-HMS-ROOTS ; -- /************************************* -- * The Power Supply Group * -- *************************************/ psMonitored OBJECT-TYPE SYNTAX INTEGER ( 0..8 ) ACCESS read-only STATUS mandatory DESCRIPTION "Number of power supply connected to this NE." ::= { psIdent 1 } -- !! 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

a little help
by Diego Gonzalez 26 May '01

26 May '01

hi i'm trying to do a program takes the oid of a trap and shows the information of that trap, name, description. how could i do this? i haven't find any example about how to do it, other problem that i have is that i almost know nothing about how snmp works, could you point. Thanks. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- !! 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 5

Re: [libsmi] a little help
by Bill Fenner 22 May '01

22 May '01

Something that does more or less what you want is included with libsmi, in the tools directory -- "smiquery". For example: mango% smiquery node IF-MIB::linkDown MibNode: IF-MIB::linkDown OID: 1.3.6.1.6.3.1.1.5.3 ParentNode: SNMPv2-MIB::snmpTraps Declaration: NOTIFICATIONTYPE NodeKind: notification Objects: IF-MIB::ifIndex IF-MIB::ifAdminStatus IF-MIB::ifOperStatus Status: current Description: A linkDown trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus. Bill -- !! 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] libsmi for Windows
by Yigal Hochberg 18 May '01

18 May '01

Hi vishal, Some of the lib files has special compilation flags and therefore as specific rules in the win/makefile (or better win/Makefile). If you changed, let say, lib/x.c (file in lib dir), cd to win and "nmake x.obj" (or better gmake x.obj). You can just use plane nmake (or gmake) to rebuilt the .exe. If you like msdev you can create an ms "project" and change cflags for individual files as in win makefile/GNUmakefile. If you do so, please publish the .dsp file so Frank can add it to cvs. Hope this helps. Regards, vishal lalit <vlalit(a)bhartitelesoft.com> wrote: > > Hi Yigal > Thanks for your help. > basically what i want to know is that how to make the smi.lib using msvc++. > this is done in the package using make file. i want to do it on my own by > using the files present in lib. i want to change the code of some files. but > when i try to compile the file i mentioned gives me the compilation error. > Thanks > vishal > ----- Original Message ----- > From: Yigal Hochberg <hochberg(a)dmhsoftware.com> > To: <vlalit(a)bhartitelesoft.com> > Cc: <libsmi(a)ibr.cs.tu-bs.de> > Sent: Thursday, May 17, 2001 5:43 PM > Subject: Re: [libsmi] libsmi for Windows > > > > > > Hi vishal, > > > > The current libsmi 0.2.16 compiles "out-of-the-box" in win subdir with > > msvc 6.0. The .exe outcome work ok too. To build, please follow the > > readme files in win subdir. > > > > Thanks, > > > > vishal lalit <vlalit(a)bhartitelesoft.com> wrote: > > > > > > hi all > > > i am using current libsmi version for windows.=20 > > > i am facing problems in compiling scanner-smi.c. > > > it is giving error > > > undefined symbol *lvalp > > > and Undefined parser > > > can anybody help me? > > > > > > Regards > > > vishal > > > > > > > > > -- > > - Yigal > > > > > > > > -- > > !! 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. > > > > -- - Yigal -- !! 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 for Windows
by vishal lalit 17 May '01

17 May '01

hi all i am using current libsmi version for windows. i am facing problems in compiling scanner-smi.c. it is giving error undefined symbol *lvalp and Undefined parser can anybody help me? Regards vishal

2 1

Newly installed 0.2.16 generates errors. Installation problem?
by Sam Mohan 15 May '01

15 May '01

I just installed libsmi-0.2.16 in my solaris server. I get this following error message when I try to generate the oid tree: ->smidump -f tree NICKEL-GLOBAL-REGISTRY.mib > ./treeOut NICKEL-GLOBAL-REGISTRY.mib:17: identifier `MODULE-IDENTITY' cannot be imported from module `SNMPv2-SMI' NICKEL-GLOBAL-REGISTRY.mib:17: identifier `OBJECT-IDENTITY' cannot be imported from module `SNMPv2-SMI' NICKEL-GLOBAL-REGISTRY.mib:49: invalid STATUS `current' in SMIv1 MIB NICKEL-GLOBAL-REGISTRY.mib:58: invalid STATUS `current' in SMIv1 MIB NICKEL-GLOBAL-REGISTRY.mib:67: invalid STATUS `current' in SMIv1 MIB I would like to get rid of these errors. (This mib file compiles without errors in SMICng and other mib compilers and the generated also tree appears to be correct.) TIA Sam

3 2

New Python wrapper
by Keith Dart 15 May '01

15 May '01

New! Improved! Attached is a Python language wrapper for the libsmi library. This one is actually usable, but perhaps is not fully complete. It's mostly a SWIG generated wrapper. See the INSTALL file for more details. Parts of it are ugly, but it works. I may (some day...) re-do one by hand. But the interface provided by the SMI meta-wrapper should not change. Enjoy, \\|// (O O) -- --------------------oOOo~(_)~oOOo---------------------------------------- Keith Dart <mailto:kdart@kdart.com> <http://www.kdart.com/> ---------------------------------------------------------------------------- Ever since my brain transplant I ... ============================================================================

2 1

Why don't BASETYPE values match RFC 2578?
by Keith Dart 15 May '01

15 May '01

I'm trying to map libsmi BASETYPE values to SNMP base types. RFC 2578 defines the base types as: Integer32 <=> INTEGER OctetString <=> OCTET STRING ObjectIdentifier <=> OBJECT IDENTIFIER IpAddress Counter32 Gauge32 Unsigned32 TimeTicks Opaque Counter64 And that's it. These all map to unique BER encodings, and are thus the only real types that can be conveyed across the wire. Yet, the libsmi constants are these: typedef enum SmiBasetype { SMI_BASETYPE_UNKNOWN = 0, SMI_BASETYPE_INTEGER32 = 1, SMI_BASETYPE_OCTETSTRING = 2, SMI_BASETYPE_OBJECTIDENTIFIER = 3, SMI_BASETYPE_UNSIGNED32 = 4, SMI_BASETYPE_INTEGER64 = 5, SMI_BASETYPE_UNSIGNED64 = 6, SMI_BASETYPE_FLOAT32 = 7, SMI_BASETYPE_FLOAT64 = 8, SMI_BASETYPE_FLOAT128 = 9, SMI_BASETYPE_ENUM = 10, SMI_BASETYPE_BITS = 11 } SmiBasetype; Libsmi adds some extra ones, and omits others. Here's my problem (by way of example). In RFC1271 (RMON MIB) there is a node like so: bufferControlTurnOnTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime when this capture buffer was first turned on." ::= { bufferControlEntry 11 } Note that the SYNTAX clause is TimeTicks, which is an SNMP base type with encoding [APPLICATION 3]. But libsmi returns this (using my Python wrapper): Python> import SMI Python> m =SMI.getModule("RFC1271-MIB") Python> n = m.getNode("bufferControlTurnOnTime") Python> print n.syntax Type: namednumbers = [] name = TimeTicks units = None enumeration = None ranges = None value = <unknown> basetype = 4 format = None reference = None description = None decl = 2 status = 0 The name is correctly shown as "TimeTicks", but the basetype is 4, which means SMI_BASETYPE_UNSIGNED32, which implies a basetype of Unsigned32 which has an encoding of [APPLICATION 2] (different from the canonical TimeTicks). But then, the SmiBasetype C enumeration does not even list TIMETICKS at all. Or am I not using this libsmi correctly? Could someone please explain this to me, and possibly give me a clue as to how to map libsmi SYNTAX/SmiType values to canonical SNMP/RFC2578 types? Thank you. \\|// (O O) -- --------------------oOOo~(_)~oOOo---------------------------------------- Keith Dart <mailto:kdart@kdart.com> <http://www.kdart.com/> ---------------------------------------------------------------------------- Ever since my brain transplant I ... ============================================================================ -- !! 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

problem with python output of smidump
by Keith Dart 08 May '01

08 May '01

I've discovered a problem with the way the smidump dumps MIBs. Right now, everything is a dictionary. Dictionaries within dictionaries. That's ok in most cases, but the problem is that a dictionary returns values in arbitrary order (since it's really a hash table). At least one element requires retrieval in a specific order, namely the INDEX construct. For example: INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr, rtpSessionIndex } The OID instance identifier part needs to be constructed in the exact order given here. But the python dump will return this in an undefined order (usually mixed up). So it's not possible to intelligently construct an index from the Python MIB. I've include a patch with is really a quick-and-dirty fix to enable something I was working on. It just makes the INDEX a list. But it will lose some other information, and fail in some circumstances. So it's not the ultimate fix, but might help someone in a similiar situation. I should probably abandon this tack and return to the pysmi wrapper... \\|// (O O) -- --------------------oOOo~(_)~oOOo---------------------------------------- Keith Dart <mailto:kdart@kdart.com> <http://www.kdart.com/> ---------------------------------------------------------------------------- Ever since my brain transplant I ... ============================================================================

2 1

Patch for lib/Makefile.in
by Harrie Hazewinkel 04 May '01

04 May '01

Hi, Attached is a patch that reduces the use of the "parser-smi.tab.c" and "parser-sming.tab.c" into "parser-smi.c" and "parser-sming.c" at the compilation stage. I have seen on some systems that libtool is not able to handle c-source filenames correctly that have multiple "." in them. This patch reduces the use of those for the compilation stage. It would be appreciated if it could be embedded in libsmi. Harrie -- phone: +39-3474932300 http://www.lisanza.net/ --- lib/Makefile.in-orig Thu May 3 13:56:19 2001 +++ lib/Makefile.in Thu May 3 13:59:33 2001 @@ -112,7 +112,7 @@ man_MANS = libsmi.3 smi_config.3 smi_module.3 smi_macro.3 smi_node.3 smi_type.3 lib_LTLIBRARIES = libsmi.la -libsmi_la_SOURCES = data.c check.c error.c util.c smi.c parser-smi.tab.c scanner-smi.c parser-sming.tab.c scanner-sming.c +libsmi_la_SOURCES = data.c check.c error.c util.c smi.c parser-smi.c scanner-smi.c parser-sming.c scanner-sming.c libsmi_la_LDFLAGS = -version-info @VERSION_LIBTOOL@ mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs @@ -128,7 +128,7 @@ LIBS = @LIBS@ libsmi_la_LIBADD = libsmi_la_OBJECTS = data.lo check.lo error.lo util.lo smi.lo \ -parser-smi.tab.lo scanner-smi.lo parser-sming.tab.lo scanner-sming.lo +parser-smi.lo scanner-smi.lo parser-sming.lo scanner-sming.lo COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) @@ -347,10 +347,10 @@ parser-sming.h error.lo error.o : error.c ../config.h smi.h error.h data.h \ errormacros.h -parser-smi.tab.lo parser-smi.tab.o : parser-smi.tab.c ../config.h smi.h \ +parser-smi.lo parser-smi.o : parser-smi.c ../config.h smi.h \ error.h data.h errormacros.h parser-smi.h scanner-smi.h check.h \ util.h -parser-sming.tab.lo parser-sming.tab.o : parser-sming.tab.c ../config.h \ +parser-sming.lo parser-sming.o : parser-sming.c ../config.h \ smi.h error.h data.h errormacros.h parser-sming.h \ scanner-sming.h check.h util.h parser-smi.h scanner-smi.lo scanner-smi.o : scanner-smi.c ../config.h error.h data.h \ @@ -447,21 +447,20 @@ maintainer-clean-generic clean mostlyclean distclean maintainer-clean -parser-smi.tab.c: parser-smi.y scanner-smi.h parser-smi.h +parser-smi.c: parser-smi.y scanner-smi.h parser-smi.h @if [ "$(BISON)" ] ; then \ echo "$(BISON)" -v -t -d -psmi parser-smi.y ; \ "$(BISON)" -v -t -d -psmi parser-smi.y ; \ else \ echo "" ; \ - echo "NOTE: we cannot build the new parser-smi.tab.c from parser-smi.y" ; \ + echo "NOTE: we cannot build the new parser-smi.c from parser-smi.y" ; \ echo "" ; \ fi # # bison-1.25 has a wrong yyparse() definition for pure reentrant code. sed -e 's/int yyparse (void);/int yyparse ();/' \ - parser-smi.tab.c > parser-smi.tab.c.tmp && \ - mv parser-smi.tab.c.tmp parser-smi.tab.c + parser-smi.tab.c > parser-smi.c -parser-sming.tab.c: parser-sming.y scanner-sming.h parser-sming.h +parser-sming.c: parser-sming.y scanner-sming.h parser-sming.h @if [ "$(BISON)" ] ; then \ echo "$(BISON)" -v -t -d -psming parser-sming.y ; \ "$(BISON)" -v -t -d -psming parser-sming.y ; \ @@ -472,8 +471,7 @@ fi # # bison-1.25 has a wrong yyparse() definition for pure reentrant code. sed -e 's/int yyparse (void);/int yyparse ();/' \ - parser-sming.tab.c > parser-sming.tab.c.tmp && \ - mv parser-sming.tab.c.tmp parser-sming.tab.c + parser-sming.tab.c > parser-sming.c scanner-smi.c: scanner-smi.l scanner-smi.h parser-smi.tab.h @if [ "$(FLEX)" ] ; then \

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 May 2001