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

has anyone tried a port for Solaris 2.6/SPARC?
by Andrew Hood 27 Jan '00

27 Jan '00

Has anyone done this? I tried libsmi-0.1.8 and built with bison 1.25, flex 2.5.4, and gcc either 2.7.2.3 or 2.8.1. I've found three items so far. 1. Probably minor. Shouldn't 18446744073709551615 be typed? (And the 0 a couple of lines above just for consistency.) I notice that by 0.1.9-pre9 it acquired UL but my versions of gcc want ULL. --- lib/parser-smi.y.orig Tue Dec 14 02:54:12 1999 +++ lib/parser-smi.y Thu Jan 27 13:21:40 2000 @@ -1030,9 +1030,9 @@ $4->basetype = SMI_BASETYPE_UNSIGNED64; if ($4->listPtr) { ((Range *)$4->listPtr->ptr)->minValuePtr->basetype = SMI_BASETYPE_UNSIGNED64; - ((Range *)$4->listPtr->ptr)->minValuePtr->value.unsigned64 = 0; + ((Range *)$4->listPtr->ptr)->minValuePtr->value.unsigned64 = 0ULL; ((Range *)$4->listPtr->ptr)->maxValuePtr->basetype = SMI_BASETYPE_UNSIGNED64; - ((Range *)$4->listPtr->ptr)->maxValuePtr->value.unsigned64 = 18446744073709551615; + ((Range *)$4->listPtr->ptr)->maxValuePtr->value.unsigned64 = 18446744073709551615ULL; } setTypeParent($4, NULL, "Unsigned64"); } 2. You can't run "make check" until you have run "make install". It looks like "check" doesn't look for the mib files in the build tree. I suggest: --- test/Makefile.am.orig Wed Oct 6 16:12:04 1999 +++ test/Makefile.am Thu Jan 27 18:16:20 2000 @@ -11,6 +11,8 @@ # @(#) $Id: Makefile.am,v 1.11 1999/10/06 06:12:04 strauss Exp $ # +TESTMIBTOPDIR = ../mibs +TESTMIBDIR = $(TESTMIBTOPDIR)/ietf:$(TESTMIBTOPDIR)/iana:$(TESTMIBTOPDIR)/irtf:$(TESTMIBTOPDIR)/site TESTMIBS = SNMPv2-MIB IF-MIB MAU-MIB RMON2-MIB TESTS = smilint-smiv2.test \ @@ -27,7 +29,7 @@ smidump-corba-oid.test \ parser.test -TESTS_ENVIRONMENT = SMIPATH="@smipath@:" TESTMIBS="$(TESTMIBS)" +TESTS_ENVIRONMENT = SMIPATH="$(TESTMIBDIR)" TESTMIBS="$(TESTMIBS)" EXTRA_DIST = $(TESTS) filter This is one of many dumps I got from during "make check" before I ran "make install". test:gdb ../tools/.libs/smidump core GNU gdb 4.17 Core was generated by `smidump -f smiv2 dumps/RMON2-MIB.smiv2'. Program terminated with signal 11, Segmentation Fault. Reading symbols from /home/u/NetCmmnd/source/SNMP/libsmi-0.1.8/tools/../lib/.libs/libsmi.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. #0 duplicateType (templatePtr=0x0, flags=0, parserPtr=0xeffff590) at data.c:2042 2042 typePtr->basetype = templatePtr->basetype; (gdb) bt #0 duplicateType (templatePtr=0x0, flags=0, parserPtr=0xeffff590) at data.c:2042 #1 0xef74eb78 in smiparse (parserPtr=0xeffff590) at parser-smi.y:1148 #2 0xef749660 in loadModule (modulename=0xeffff865 "dumps/RMON2-MIB.smiv2") at data.c:3127 #3 0xef74b618 in smiLoadModule (module=0xeffff865 "dumps/RMON2-MIB.smiv2") at smi.c:782 #4 0x11d30 in main (argc=4, argv=0xeffff714) at smidump.c:195 (gdb) $10 can be null when passed as a parameter to duplicateType. Should that be a nested if or reported as an error condition? 3. The test scripts assume you have GNU diff. Solaris's doesn't take the same parameters. The setup of the diff program should be determined by ./configure similar to the usual search for gawk/nawk/awk. e.g. my version of GNU diff is gdiff, so look for gdiff/diff, then test the version. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCM/CS/M d+ s+:+ a+ C++ UAHLS++++$ P++ L++>+++ E- W-- N++ o !K w--- O+ M !V PS+ PE+ Y PGP t+ 5? X+ R* tv+ b++ DI+++ !D G e++ h---->--- r+++ y++++ ------END GEEK CODE BLOCK------ -- !! 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

Porting libsmi to FreeBSD
by Marcin Cieslak 26 Jan '00

26 Jan '00

Hello, I am proud to introduce myself as a FreeBSD libsmi port maintainer. One thing I would like to verify: when I install libsmi with "make install" target it seems that "mibs" directory contains only "iana", "ietf", and so on directories and no MIBs there, although they reside in a source tree. Is it intentional/unfinished? Can I just copy them using a post-install shell script? -- << Marcin Cieslak // saper(a)system.pl >> ----------------------------------------------------------------- SYSTEM Internet Provider http://www.system.pl -- !! 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: generating CORBA-IDL using smidump
by Frank Strauss 11 Jan '00

11 Jan '00

Hi! dongquan> I am a graduate student and a new comer of CORBA-base dongquan> network managemnt. I am very interesting in your dongquan> libsmi for compiling SNMP MIB into CORBA-IDL. I dongquan> downloaded a copy and installed it in linux. dongquan> I can compile MIB into CORBA-IDL using smidump utility dongquan> but when I compile the MIB-IDL under omniOrb it fail. dongquan> some include files like ASN1Type.idl can not be found. dongquan> what's wrong with me? I found the examples in test dongquan> directory are very good. How can I do it best? The CORBA-IDL dump modules produce output according to the JIDM specs (a probably obsolete location is http://www.opengroup.org/onlinepubs/8349099/toc.htm). These specifications include the basic IDL definitions you are looking for. Subrata Mazumdar did most of the work on these specifications. May be you find the source files on his home page (http://www.bell-labs.com/user/mazum/). Or may be Juergen Schoenwaelder (Cc), who worked on the libsmi CORBA-IDL dump module, can help. 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 relead 0.1.8
by Frank Strauss 14 Dec '99

14 Dec '99

Hi! It's christmas time. Some changes happened to the libsmi project making a new release worthwhile... o Some libsmi behaviour can now be configured through a global and a user level configuration file, e.g. the error level may be raised and a set of boring warning messages may be hidden for use with smilint, while other applications set the error level to a minimum value or preload some special MIB modules. o Some MIB modules have been updated and added. o smistrip is now part of the libsmi distribution. It is a shell/awk script to extract MIB modules from documents like RFCs and I-Ds. o A handfull of bugs have been fixed. Furthermore, it's worth to mention that... o The tcpdump code available from www.tcpdump.org now contains an updated print-snmp module that uses libsmi to is capable to print nice human readable varbind lists. It also checks for some MIB violating SNMP traffic. Very usesful for SNMP application development. o The GxSNMP project (www.gxsnmp.org) uses libsmi. As usual the current release 0.1.8 can be found at http://www.ibr.cs.tu-bs.de/projects/libsmi/ ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/ Have fun with it, 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] Result dependent on MIB file order
by Frank Strauss 07 Oct '99

07 Oct '99

Hi! Jochen> this happens with the RADIUS MIB files in rfc2620.txt and Jochen> rfc2621.txt. Dependent on the order of reading these files, Jochen> only on MIB or both MIBs are added to the MIB tree. [...] This has been fixed in an intermediate pre-release and also in 0.1.7, of course. 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.7
by Frank Strauss 07 Oct '99

07 Oct '99

Hi! The libsmi project is still alive! More than that, after a long silent break, we started to add some new features and banish more nasty bugs a few weeks ago. The most important changes are: o Some more errors and warnings in SMIv1/v2/ng modules are now detected (illegal display hints, illegal type restrictions in sequences, duplicated groups or object refinements in a single compliance statement, identifier differences limited to case). o A hand full of bugs leading to wrong or inconsistent data visible at the API, to endless loops, or to crashes have been fixed. o A few smidump output formats have been added: CORBA IDL and OID files according to the JIDM specs, a nice tree of object definitions, UCD-mib2c-like header and code stubs. o Other formats like the type definition tree and imports tree have been beautified and cleaned up. The SMI formats now generate a cleaned up list of imported identifiers. o A huge amount of (nearly?) all IETF and IANA standard MIB modules as of September 6th 1999 and some additional modules have been incorporated (this enlarges the tarball to 1.6MB). These modules have been built from scratch by extracting them from the RFCs and applying the required changes in cases where real SMI violating bugs have been present. A Web page also lists those modules, their errors and the required changes. See below. o A set of regression tests against some of the incorporated MIB modules has been added. o Some source files have been reorganized. o Some slight changes at the API where necessary: SmiValue's are no longer linked by pointers, but integrated into the API structs. Some GetFirst/GetNext() functions are gone and replaced by smiGetFirstListItem/smiGetNextListItem(). o Besides Solaris and Linux, the code now compiles on FreeBSD and Cygnus Win32 platforms. Other platforms should be fine as well, but not yet tested. o A few more minor changes. See the ChangeLog file for more details. Currently, the man pages and other documentation are not up to date. Sorry, hopefully this will change soon. Anyway, as usual the current release 0.1.7 can be found at ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/ The list of all IANA mantained and IETF standard MIB modules can be found at http://www.ibr.cs.tu-bs.de/projects/libsmi/mibs.html Have fun with it, 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

Result dependent on MIB file order
by Jochen Friedrich 06 Aug '99

06 Aug '99

1 0

Re: [libsmi] Re: [gxsnmp] next core ....
by Frank Strauss 06 Aug '99

06 Aug '99

Jochen Friedrich <jochen(a)scram.de> writes: > > /usr/share/gxsnmp/mibs/SNMP-TARGET-MIB:9: Identifier > > `TEXTUAL-CONVENTION' cannot be imported from module `SNMPv2-SMI' > > /usr/share/gxsnmp/mibs/SNMP-PROXY-MIB:17: parse error See the updated modules from RFC 2573. They can be found on my `Standard MIBs Bug Hit List' at http://www.ibr.cs.tu-bs.de/projects/libsmi/mibs.html > > Segmentation fault (core dumped) > > So it looks like libsmi doesn't recover from earlier parse errors. Yes. I hope, I will find time to get this more robust in the future. -- !! 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: [gxsnmp] next core ....
by Jochen Friedrich 06 Aug '99

06 Aug '99

Hi Eddie, > /usr/share/gxsnmp/mibs/SNMPv2-PDU: This is no MIB, but a definition of the PDU. (OK, this should be removed from the mibs directory). > /usr/share/gxsnmp/mibs/SNMP-TARGET-MIB:9: Identifier > `TEXTUAL-CONVENTION' cannot be imported from module `SNMPv2-SMI' This MIB seems to be buggy. > /usr/share/gxsnmp/mibs/SNMP-PROXY-MIB:17: parse error This MIB is buggy, as well (extra colon). > /usr/share/gxsnmp/mibs/COMMUNITY-BASED-SNMPv2 This is yet another PDU. :16: Illegal keyword `ANY' > /usr/share/gxsnmp/mibs/SNMP-COMMUNITY-MIB:9: Identifier `UInteger32' > cannot be imported from module `SNMPv2-SMI' > /usr/share/gxsnmp/mibs/SNMP-COMMUNITY-MIB:64: Object identifier element > `xxx' name only allowed as first element This MIB is still experimental and contains 'xxx' as placeholder for the final assigned id. > Segmentation fault (core dumped) > # So it looks like libsmi doesn't recover from earlier parse errors. Please remove the marked mibs from ~/.gnome/gxsnmp and the problems should disappear. Cheers, 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

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