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

Invitation to connect on LinkedIn
by Pete Wilson 10 Jun '11

10 Jun '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Pete Pete Wilson Contract software engineer at www.pwilson.net Greater Boston Area Confirm that you know Pete Wilson https://www.linkedin.com/e/-sqf3rv-gorc5ofi-6j/isd/3175146899/dgUlWFDb/ -- (c) 2011, LinkedIn Corporation

1 0

Potential bug in forward nodes references (this time with no awful horizontal wrapping...)
by cedric arbogast 09 May '11

09 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, This is my first contact and mail with this mailing list, to summarize i'm a coder maintening a personnal home server using several GNU tools since the late 90's. I build LIBMSI-0.4.8 in a chroot jail (gcc 4.5.2/libc 2.13/binutils 2.21/make 3.82) with an athlon architecture on ext3 FS and, as root,got one failed test on tests/parser : [root@pompomgalli] mkdir libmsi-0.4.8_build && cd libmsi-0.4.8_build [root@pompomgalli] ../libsmi-0.4.8/configure --prefix=/usr checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes .... [root@pompomgalli] make .... make[2]: Leaving directory `/usr/src_app/libsmi-0.4.8_build' make[1]: Leaving directory `/usr/src_app/libsmi-0.4.8_build' [root@pompomgalli] make check ... PASS: smidump-orig-smiv2.test comparing `smidump -f smiv2 ../dumps/smiv2/SNMPv2-MIB' output with dumps/smiv2-smiv2/*. comparing `smidump -f smiv2 ../dumps/smiv2/IF-MIB' output with dumps/smiv2-smiv2/*. comparing `smidump -f smiv2 ../dumps/smiv2/MAU-MIB' output with dumps/smiv2-smiv2/*. comparing `smidump -f smiv2 ../dumps/smiv2/RMON2-MIB' output with dumps/smiv2-smiv2/*. PASS: smidump-smiv2-smiv2.test Checking LIBSMI-TEST-001-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-002-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-003-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-004-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-005-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-006-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-007-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-008-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-009-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-010-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-011-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-012-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-013-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-014-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-015-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-016-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-017-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-018-MIB. unexpected output. see parser.out directory. FAIL: parser.test checking smidiff results for *. /bin/diff: *.diff: No such file or directory PASS: smidiff.test ==================== 1 of 21 tests failed ==================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make: *** [check-recursive] Error 1 [root@pompomgalli] Therefore, i check one of the failed output : [root@pompomgalli] cat test/parser.out/LIBSMI-TEST-003-MIB.err [root@pompomgalli] cat test/parser.out/LIBSMI-TEST-003-MIB.expect LIBSMI-TEST-003-MIB:45: more than one MODULE-IDENTITY clause in SMIv2 MIB LIBSMI-TEST-003-MIB:45: MODULE-IDENTITY clause must be the first declaration in a module LIBSMI-TEST-003-MIB:53: revision not in reverse chronological order I then launch manually the LIBSMI-TEST-003-MIB test : [root@pompomgalli] SMIPATH=$SMIPATH:../libsmi-0.4.8/mibs/ietf:../libsmi-0.4.8/mibs:../libsmi-0.4.8/test/mibs tools/smilint -c/dev/null -l9 ../libsmi-0.4.8/test/mibs/LIBSMI-TEST-003-MIB 2>&1 Segmentation fault (core dumped) [root@pompomgalli] I have 'straced' the test but found nothing noticeable. As i am too lazy to launch gdb, i have first googling about related troubles regarding libsmi and found Vincent Bernat mail (http://www.ibr.cs.tu-bs.de/pipermail/libsmi/2010-August/001214.html). So, starting from his premises, i looked after the handling of module's nodes trees, and, to resume, seen that Vincent Bernat seems to be right when commenting the freeNodeTree and smiFree calls in loadModule (data.c). The nodes allocated for the module could have been referenced by the parser and used later in the parse process (case 344 in parser-smi.c), therefore they should not be freed at the end of the loadModule call but at the end of the parse process (imho). While i was investigate, i have also noticed that the checkObjects method in parser-smi.c does not handle the case of a malformed tree where a node could not have been linked to the root tree while searching possibly incorrect oidlen/oid values. I suggest theses two patchs to address that : --- ../libsmi-0.4.8/lib/parser-smi.c.orig 2008-04-18 14:58:11.000000000 +0200 +++ ../libsmi-0.4.8/lib/parser-smi.c 2011-05-08 16:33:24.000000000 +0200 @@ -954,6 +954,7 @@ nodePtr->parentPtr != thisParserPtr->pendingNodePtr && nodePtr->parentPtr != smiHandle->rootNodePtr && nodePtr != nodePtr->parentPtr && + nodePtr->parentPtr != NULL && i <= 128; nodePtr = nodePtr->parentPtr, i++); if ((objectPtr->export.name) && --- ../libsmi-0.4.8/lib/data.c.orig 2008-04-18 12:42:50.000000000 +0200 +++ ../libsmi-0.4.8/lib/data.c 2011-05-08 16:24:21.000000000 +0200 @@ -4737,8 +4737,9 @@ smiDepth++; parser.line = 1; smiparse((void *)&parser); - freeNodeTree(parser.pendingNodePtr); - smiFree(parser.pendingNodePtr); + // Nodes must NOT be freed here because forward references could be reached by imported modules ref + // freeNodeTree(parser.pendingNodePtr); + // smiFree(parser.pendingNodePtr); smiLeaveLexRecursion(); smiDepth--; fclose(parser.file); @@ -4780,6 +4781,9 @@ smiDepth++; parser.line = 1; smingparse((void *)&parser); + // Nodes must NOT be freed here because forward references could be reached by imported modules ref + // freeNodeTree(parser.pendingNodePtr); + // smiFree(parser.pendingNodePtr); freeNodeTree(parser.pendingNodePtr); smiFree(parser.pendingNodePtr); smingLeaveLexRecursion(); For parser-smi.c, it seems that quitting the loop when the node's parent is null is right regarding the goal to control that the tree does not exceed 128 nodes. Perhaps it could be useful to add an error message when this loop detects an 'unlinked' node. With theses patchs, the parser test gives the following results : [root@pompomgalli] make check ... PASS: smidump-smiv2-smiv2.test Checking LIBSMI-TEST-001-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-002-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-003-MIB. 3 errors/warnings, ok. Checking LIBSMI-TEST-004-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-005-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-006-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-007-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-008-MIB. 21 errors/warnings, ok. Checking LIBSMI-TEST-009-MIB. 23 errors/warnings, ok. Checking LIBSMI-TEST-010-MIB. 10 errors/warnings, ok. Checking LIBSMI-TEST-011-MIB. 3 errors/warnings, ok. Checking LIBSMI-TEST-012-MIB. 5 errors/warnings, ok. Checking LIBSMI-TEST-013-MIB. 14 errors/warnings, ok. Checking LIBSMI-TEST-014-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-015-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-016-MIB. 10 errors/warnings, ok. Checking LIBSMI-TEST-017-MIB. 12 errors/warnings, ok. Checking LIBSMI-TEST-018-MIB. 1 errors/warnings, ok. FAIL: parser.test checking smidiff results for *. /bin/diff: *.diff: No such file or directory PASS: smidiff.test ==================== 1 of 21 tests failed ==================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make: *** [check-recursive] Error 1 The LIBSMI-TEST-014-MIB is still failing with : [root@pompomgalli] diff -u test/parser.out/LIBSMI-TEST-014-MIB.err test/parser.out/LIBSMI-TEST-014-MIB.expect --- test/parser.out/LIBSMI-TEST-014-MIB.err 2011-05-08 17:50:51.000000000 +0200 +++ test/parser.out/LIBSMI-TEST-014-MIB.expect 2011-05-08 17:50:51.000000000 +0200 @@ -1,5 +1,7 @@ +LIBSMI-TEST-014-MIB:102: warning: index of row `barEntry' can exceed OID size limit by 1 subidentifier(s) +LIBSMI-TEST-014-MIB:186: warning: index of row `barImpliedEntry' can exceed OID size limit by 1 subidentifier(s) LIBSMI-TEST-014-MIB:251: index element `fooStringName' of row `fooStringEntry' must have a size restriction -LIBSMI-TEST-014-MIB:230: warning: index of row `fooStringEntry' can exceed OID size limit by 65421 subidentifier(s) +LIBSMI-TEST-014-MIB:230: warning: index of row `fooStringEntry' can exceed OID size limit by 65427 subidentifier(s) LIBSMI-TEST-014-MIB:294: index element `fooOidName' of row `fooOidEntry' should but cannot have a size restriction -LIBSMI-TEST-014-MIB:273: warning: index of row `fooOidEntry' can exceed OID size limit by 14 subidentifier(s) +LIBSMI-TEST-014-MIB:273: warning: index of row `fooOidEntry' can exceed OID size limit by 20 subidentifier(s) LIBSMI-TEST-014-MIB:309: warning: current group `fooOidBarGroup' is not referenced in this module Apparently, it is something else, i could investigate if it seems pertinent. I will maintain my chroot environment for few days, therefore i could make more tests if needed. Regards, Cedric. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3GxxUACgkQUPHT03kXaaZ9GgCghDhzqAyqwE7e2ZsV6C/ujzrR xooAnAtztelJGUsQOgvV3Y4Jp4AMXgH7 =a/54 -----END PGP SIGNATURE-----

2 1

Potential bug in forward nodes references
by cedric arbogast 08 May '11

08 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, This is my first contact and mail with this mailing list, to summarize i'm a coder maintening a personnal home server using several GNU tools since the late 90's. I build LIBMSI-0.4.8 in a chroot jail (gcc 4.5.2/libc 2.13/binutils 2.21/make 3.82) with an athlon architecture on ext3 FS and, as root, got one failed test on tests/parser : [root@pompomgalli] mkdir libmsi-0.4.8_build && cd libmsi-0.4.8_build [root@pompomgalli] ../libsmi-0.4.8/configure --prefix=/usr checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes .... [root@pompomgalli] make .... make[2]: Leaving directory `/usr/src_app/libsmi-0.4.8_build' make[1]: Leaving directory `/usr/src_app/libsmi-0.4.8_build' [root@pompomgalli] make check ... PASS: smidump-orig-smiv2.test comparing `smidump -f smiv2 ../dumps/smiv2/SNMPv2-MIB' output with dumps/smiv2-smiv2/*. comparing `smidump -f smiv2 ../dumps/smiv2/IF-MIB' output with dumps/smiv2-smiv2/*. comparing `smidump -f smiv2 ../dumps/smiv2/MAU-MIB' output with dumps/smiv2-smiv2/*. comparing `smidump -f smiv2 ../dumps/smiv2/RMON2-MIB' output with dumps/smiv2-smiv2/*. PASS: smidump-smiv2-smiv2.test Checking LIBSMI-TEST-001-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-002-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-003-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-004-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-005-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-006-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-007-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-008-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-009-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-010-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-011-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-012-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-013-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-014-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-015-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-016-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-017-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-018-MIB. unexpected output. see parser.out directory. FAIL: parser.test checking smidiff results for *. /bin/diff: *.diff: No such file or directory PASS: smidiff.test ==================== 1 of 21 tests failed ==================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make: *** [check-recursive] Error 1 [root@pompomgalli] Therefore, i check one of the failed output : [root@pompomgalli] cat test/parser.out/LIBSMI-TEST-003-MIB.err [root@pompomgalli] cat test/parser.out/LIBSMI-TEST-003-MIB.expect LIBSMI-TEST-003-MIB:45: more than one MODULE-IDENTITY clause in SMIv2 MIB LIBSMI-TEST-003-MIB:45: MODULE-IDENTITY clause must be the first declaration in a module LIBSMI-TEST-003-MIB:53: revision not in reverse chronological order I then launch manually the LIBSMI-TEST-003-MIB test : [root@pompomgalli] SMIPATH=$SMIPATH:../libsmi-0.4.8/mibs/ietf:../libsmi-0.4.8/mibs:../libsmi-0.4.8/test/mibs tools/smilint -c/dev/null -l9 ../libsmi-0.4.8/test/mibs/LIBSMI-TEST-003-MIB 2>&1 Segmentation fault (core dumped) [root@pompomgalli] I have 'straced' the test but found nothing noticeable. As i am too lazy to launch gdb, i have first googling about related troubles regarding libsmi and found Vincent Bernat mail (http://www.ibr.cs.tu-bs.de/pipermail/libsmi/2010-August/001214.html). So, starting from his premises, i looked after the handling of module's nodes trees, and, to resume, seen that Vincent Bernat seems to be right when commenting the freeNodeTree and smiFree calls in loadModule (data.c). The nodes allocated for the module could have been referenced by the parser and used later in the parse process (case 344 in parser-smi.c), therefore they should not be freed at the end of the loadModule call but at the end of the parse process (imho). While i was investigate, i have also noticed that the checkObjects method in parser-smi.c does not handle the case of a malformed tree where a node could not have been linked to the root tree while searching possibly incorrect oidlen/oid values. I suggest theses two patchs to address that : --- ../libsmi-0.4.8/lib/parser-smi.c.orig 2008-04-18 14:58:11.000000000 +0200 +++ ../libsmi-0.4.8/lib/parser-smi.c 2011-05-08 16:33:24.000000000 +0200 @@ -954,6 +954,7 @@ nodePtr->parentPtr != thisParserPtr->pendingNodePtr && nodePtr->parentPtr != smiHandle->rootNodePtr && nodePtr != nodePtr->parentPtr && + nodePtr->parentPtr != NULL && i <= 128; nodePtr = nodePtr->parentPtr, i++); if ((objectPtr->export.name) && --- ../libsmi-0.4.8/lib/data.c.orig 2008-04-18 12:42:50.000000000 +0200 +++ ../libsmi-0.4.8/lib/data.c 2011-05-08 16:24:21.000000000 +0200 @@ -4737,8 +4737,9 @@ smiDepth++; parser.line = 1; smiparse((void *)&parser); - freeNodeTree(parser.pendingNodePtr); - smiFree(parser.pendingNodePtr); + // Nodes must NOT be freed here because forward references could be reached by imported modules ref + // freeNodeTree(parser.pendingNodePtr); + // smiFree(parser.pendingNodePtr); smiLeaveLexRecursion(); smiDepth--; fclose(parser.file); @@ -4780,6 +4781,9 @@ smiDepth++; parser.line = 1; smingparse((void *)&parser); + // Nodes must NOT be freed here because forward references could be reached by imported modules ref + // freeNodeTree(parser.pendingNodePtr); + // smiFree(parser.pendingNodePtr); freeNodeTree(parser.pendingNodePtr); smiFree(parser.pendingNodePtr); smingLeaveLexRecursion(); For parser-smi.c, it seems that quitting the loop when the node's parent is null is right regarding the goal to control that the tree does not exceed 128 nodes. Perhaps it could be useful to add an error message when this loop detects an 'unlinked' node. With theses patchs, the parser test gives the following results : [root@pompomgalli] make check ... PASS: smidump-smiv2-smiv2.test Checking LIBSMI-TEST-001-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-002-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-003-MIB. 3 errors/warnings, ok. Checking LIBSMI-TEST-004-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-005-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-006-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-007-MIB. 1 errors/warnings, ok. Checking LIBSMI-TEST-008-MIB. 21 errors/warnings, ok. Checking LIBSMI-TEST-009-MIB. 23 errors/warnings, ok. Checking LIBSMI-TEST-010-MIB. 10 errors/warnings, ok. Checking LIBSMI-TEST-011-MIB. 3 errors/warnings, ok. Checking LIBSMI-TEST-012-MIB. 5 errors/warnings, ok. Checking LIBSMI-TEST-013-MIB. 14 errors/warnings, ok. Checking LIBSMI-TEST-014-MIB. unexpected output. see parser.out directory. Checking LIBSMI-TEST-015-MIB. 0 errors/warnings, ok. Checking LIBSMI-TEST-016-MIB. 10 errors/warnings, ok. Checking LIBSMI-TEST-017-MIB. 12 errors/warnings, ok. Checking LIBSMI-TEST-018-MIB. 1 errors/warnings, ok. FAIL: parser.test checking smidiff results for *. /bin/diff: *.diff: No such file or directory PASS: smidiff.test ==================== 1 of 21 tests failed ==================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/usr/src_app/libsmi-0.4.8_build/test' make: *** [check-recursive] Error 1 The LIBSMI-TEST-014-MIB is still failing with : [root@pompomgalli] diff -u test/parser.out/LIBSMI-TEST-014-MIB.err test/parser.out/LIBSMI-TEST-014-MIB.expect --- test/parser.out/LIBSMI-TEST-014-MIB.err 2011-05-08 17:50:51.000000000 +0200 +++ test/parser.out/LIBSMI-TEST-014-MIB.expect 2011-05-08 17:50:51.000000000 +0200 @@ -1,5 +1,7 @@ +LIBSMI-TEST-014-MIB:102: warning: index of row `barEntry' can exceed OID size limit by 1 subidentifier(s) +LIBSMI-TEST-014-MIB:186: warning: index of row `barImpliedEntry' can exceed OID size limit by 1 subidentifier(s) LIBSMI-TEST-014-MIB:251: index element `fooStringName' of row `fooStringEntry' must have a size restriction -LIBSMI-TEST-014-MIB:230: warning: index of row `fooStringEntry' can exceed OID size limit by 65421 subidentifier(s) +LIBSMI-TEST-014-MIB:230: warning: index of row `fooStringEntry' can exceed OID size limit by 65427 subidentifier(s) LIBSMI-TEST-014-MIB:294: index element `fooOidName' of row `fooOidEntry' should but cannot have a size restriction -LIBSMI-TEST-014-MIB:273: warning: index of row `fooOidEntry' can exceed OID size limit by 14 subidentifier(s) +LIBSMI-TEST-014-MIB:273: warning: index of row `fooOidEntry' can exceed OID size limit by 20 subidentifier(s) LIBSMI-TEST-014-MIB:309: warning: current group `fooOidBarGroup' is not referenced in this module Apparently, it is something else, i could investigate if it seems pertinent. I will maintain my chroot environment for few days, therefore i could make more tests if needed. Regards, Cedric. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3GxD4ACgkQUPHT03kXaaaRkACgn8HDsceBfXD4e6CH2GGqwT7y TPQAoIyxL9n4F8V89YPsg6LHa+84k5Hr =G2QS -----END PGP SIGNATURE-----

1 0

Errors in parse of SNMPv2-SMI and SNMPv2-CONF
by Andrew Hood 25 Mar '11

25 Mar '11

I realise that these aren't ordinary MIBs, but the errors you get when other modules IMPORT from them are probably fixable. SNMPv2-SMI:191: range limit exceeds underlying basetype SNMPv2-SMI:191: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:196: range limit exceeds underlying basetype SNMPv2-SMI:196: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:202: range limit exceeds underlying basetype SNMPv2-SMI:202: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:207: range limit exceeds underlying basetype SNMPv2-SMI:207: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:217: range limits must be `lower-bound .. upper-bound' lib/parser-smi.y typeTag does not pick up the APPLICATION type, which could then be used to set the correct basetype and ranges. SNMPv2-CONF:4: identifier `ObjectSyntax' cannot be imported from module `SNMPv2-SMI' This one I don't understand. -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who

1 0

Problem with overlapping ranges with the same minimum value
by Göran Runfeldt 24 Mar '11

24 Mar '11

Hello, I have found a problem when using smidump 0.4.8 with certain MIB files. The MIB file from this example is private, so I have extracted the part that causes the problem: TEST-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 Unsigned32, dummyVariable FROM SNMPv2-SMI-v1 ; TestLabel ::= Unsigned32(16..8191|16..1048575) END When using smidump with the SMI or XML output formats (I have not verified the other formats) the process enters an infinite loop. The XML output looks like this: <?xml version="1.0"?>  <smi> <module name="TEST-MIB" language="SMIv1"> </module> <imports> <import module="RFC-1212" name="OBJECT-TYPE"/> <import module="" name="Unsigned32"/> <import module="" name="dummyVariable"/> </imports> <typedefs> <typedef name="TestLabel" basetype="Unsigned32"> <range min="16" max="1048575"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> ... The last line is repeated infinitely. The problem was identified to be caused by the same minimum value (16) in the two ranges. Smidump correctly warns about overlapping ranges, but this code was added to keep smidump from looping when using the -k option: --- libsmi-0.4.8-old/lib/smi.c 2008-04-18 12:42:50.000000000 +0200 +++ libsmi-0.4.8/lib/smi.c 2011-03-22 16:18:29.000000000 +0100 @@ -867,7 +867,13 @@ if ((!listPtr) || (!listPtr->nextPtr)) { return NULL; } - + + /* Check for duplicate min values in ranges and ignore those ranges + instead of going into an infinite loop. */ + if (!memcmp(&((Range *)listPtr->nextPtr->ptr)->export.minValue, + &smiRangePtr->minValue, sizeof(struct SmiValue))) + return NULL; + return &((Range *)listPtr->nextPtr->ptr)->export; } Any thoughts? //Göran

2 2

libsmi/smidump 0.4.8 problem: SYSAPPL-MIB::sysApplPastRunMaxRows SYNTAX Upper Bound
by Jens Engel 18 Mar '11

18 Mar '11

smidump 0.4.8 (up to rev13631 and maybe never) have a problem with the following SMI construct: -- FROM libsmi distributed SYSAPPL-MIB: sysApplPastRunMaxRows OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) ... NOTE: 0xFFFFFFFF = 2^32-1 = 4 294 967 295 when you try to convert the provided MIB via: smidump --format=smiv2 SYSAPPL-MIB ... you get the following output for libsmi 0.4.7 and 0.4.8. NOTE: Upper syntax bound is wrong in both cases. === modified file 'IETF/mibs/SYSAPPL-MIB.mib' --- IETF/mibs/SYSAPPL-MIB.mib 2009-03-28 19:03:48 +0000 +++ IETF/mibs/SYSAPPL-MIB.mib 2009-05-04 16:57:29 +0000 @@ -1038,7 +1038,7 @@ ::= { sysApplElmtPastRunEntry 11 } sysApplPastRunMaxRows OBJECT-TYPE - SYNTAX Unsigned32 (0..1134880) -- smidump 0.4.7 output + SYNTAX Unsigned32 (0..1134864) -- smidump 0.4.8 rev13631 (post-release) NOTE: Output of SYNTAX upper bound varies. WEIRD: The conversion to format=python leads to the correct result. Without looking at the source code, I assume that the hex-string to integer conversion has a problem. Ciao, Jens Engel Jens Engel mailto:jens_engel@t-online.de mailto:jens.engel

2 1

memory leaks in smi 0.4.8
by Fort, Andrew 28 Feb '11

28 Feb '11

> I have detected a couple of memory leaks (using Visual Leak Detector) in a > project where I parse a MIB with 4 imported MIBs. > > One (44 bytes) seems to be associated with 'parser.pendingNodePtr' > allocated > in smiInitData. (adding smiFree(parser.pendingNodePtr); at the end of the > function removes this leak). > > The 2nd leak (36 bytes) originates in smiLoadModule used to handle the MIB > parsing. The call stack returned was: > Call Stack: > c:\projects\hf sdr\msvc\smi-0.4.8\<stdout> (14160): smirealloc > c:\projects\hf sdr\msvc\smi-0.4.8\<stdout> (13871): > smiensure_buffer_stack > c:\projects\hf sdr\msvc\smi-0.4.8\<stdout> (13647): > smi_switch_to_buffer > c:\projects\hf sdr\msvc\smi-0.4.8\scanner-smi.l (82): > smiEnterLexRecursion > c:\projects\hf sdr\smi-0.4.8\lib\data.c (4733): loadModule > c:\projects\hf sdr\msvc\smi-0.4.8\parser-smi.y (1755): smiparse > c:\projects\hf sdr\smi-0.4.8\lib\data.c (4740): loadModule > > Any insights welcome. > > Regards, > > Andrew Fort. >

2 1

dependencies
by Andrew Hood 23 Jan '11

23 Jan '11

Please add errormacros.h to the dependencies of parser-yang.c GNU make on my box tries to build parser-yang.o before errormacros.h Once I added that dependency, I could even run parallel makes. $ svn diff lib/Makefile.am Index: lib/Makefile.am =================================================================== --- lib/Makefile.am (revision 32699) +++ lib/Makefile.am (working copy) @@ -51,7 +51,7 @@ parser-sming.c: parser-sming.y scanner-sming.h parser-sming.h $(BISON) --defines=parser-sming.tab.h -t -psming -o parser-sming.c parser-sming.y -parser-yang.c: parser-yang.y scanner-yang.h parser-yang.h +parser-yang.c: parser-yang.y scanner-yang.h parser-yang.h errormacros.h $(BISON) --defines=parser-yang.tab.h -t -pyang -o parser-yang.c parser-yang.y scanner-smi.c: scanner-smi.l scanner-smi.h parser-smi.tab.h -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who

2 1

question on smiInit...
by Mark Martin 14 Dec '10

14 Dec '10

I have used libsmi for a couple of projects, having said that, the one thing I have discovered in regards to smiInit (this is proven with the sample progam, smiInit takes an argument, or NULL, using NULL, it will not dump the OID tree, except for the first node, then nothing else follows... except the remaining numbers. However, if you put something (doesn't matter what) as a char * argument, the tree parse works. I have looked at the manual page many times, and even looked at the 'C' code for smiInit, and I am not sure of the full functionality of the argument, other than it adds a 'handle' in the init function, all the the man page says is 'tag:dataset' I am not sure what this means in the context it is implemented. Can someone provide more insight, as to how and why someone would used this, by a more practical explanation? I can pass "x", and the parse works, no "x:yyy", so I am not sure what this parameter would be used for other than it actually parsing the mib tree.

3 11

C++ wrapper for libSmi
by Roddy Pratt 19 Nov '10

19 Nov '10

Hi, I'm just starting to use libSmi with C++Builder (Borland/Codegear/Embarcadero), and thinking that writing a C++ wrapper would make my life a little easier. Does one exist already, and if so where? Regards, Roddy

2 1