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

Smilint web interface tool
by Jessie Jewitt 01 Nov '17

01 Nov '17

I'm using the smilint web interface tool. My MIB that I am checking contains multiple import statements from multiple MIBs. However, the web tool only allows you to specify one MIB for import. How can I specify multiple MIBs?

2 1

segfault when parsing UCD-SNMP-MIB-OLD
by Olivier Verriest 09 Aug '17

09 Aug '17

The current libsmi parser segfaults when trying to parse a MIB file which puts column definitions directly under the SEQUENCE OF definition (which is wrong, there should be a SEQUENCE row entity). An example of such a MIB file is UCD-SNMP-MIB-OLD, where 'extensibleNames' is a direct descendant of 'extensible': #0 strlen () at ../sysdeps/x86_64/strlen.S:106 #1 0x00007f1af29b1ced in _IO_vfprintf_internal (s=s@entry=0x7ffe8b90bee0, format=<optimized out>, format@entry=0x7f1af523b868 "SEQUENCE element #%d `%s' is not a child node under `%s'", ap=ap@entry=0x7ffe8b90c060) at vfprintf.c:1637 #2 0x00007f1af29d9543 in _IO_vasprintf (result_ptr=result_ptr@entry=0x7ffe8b90c020, format=0x7f1af523b868 "SEQUENCE element #%d `%s' is not a child node under `%s'", args=args@entry=0x7ffe8b90c060) at vasprintf.c:59 #3 0x00007f1af520de30 in smiVasprintf (strp=strp@entry=0x7ffe8b90c020, format=<optimized out>, ap=ap@entry=0x7ffe8b90c060) at smi.c:3090 #4 0x00007f1af5207d45 in printError (parser=0x7ffe8b90d7c0, id=<optimized out>, line=172, ap=ap@entry=0x7ffe8b90c060) at error.c:1126 #5 0x00007f1af52080bf in smiPrintErrorAtLine (parser=parser@entry=0x7ffe8b90d7c0, id=id@entry=194, line=<optimized out>) at error.c:1162 #6 0x00007f1af5224279 in checkObjects (modulePtr=<optimized out>, parserPtr=0x7ffe8b90c140) at parser-smi.y:578 #7 smiparse (parserPtr=parserPtr@entry=0x7ffe8b90d7c0) at parser-smi.y:1668 #8 0x00007f1af521159b in loadModule (modulename=modulename@entry=0x2be5838 "/usr/share/snmp/mibs/UCD-SNMP-MIB-OLD.mib", parserPtr=parserPtr@entry=0x0) at smi-data.c:4658 #9 0x00007f1af520c3ba in smiLoadModule (module=0x2be5838 "/usr/share/snmp/mibs/UCD-SNMP-MIB-OLD.mib") at smi.c:931 The following patch skips this failing parent comparison: Index: lib/parser-smi.y =================================================================== 349a350 > 350a352 > (objectPtr->typePtr->export.name == NULL || 352c354 < objectPtr->typePtr->export.name)) { --- > objectPtr->typePtr->export.name))) { 354a357 > objectPtr->export.name == NULL ? "N/A" : 578c581 < ((Object *)p->ptr)->export.name, --- > "N/A", This is only masking the symptoms though; the resulting MIB structures cannot be used. Best regards, Olivier Verriest

1 0

smiExit() fails to free one allocation ?
by Bijal Thanawala 01 Aug '16

01 Aug '16

Hi libsmi team, This is to report two issues with regards to : libsmi-0.4.8-16.fc23.x86_64 Issue #1Although smiExit() does good job of freeing memory blocks allocated by smiInit, it misses one. To be precise, 44 out of 45 allocated memory block are freed. (Details of the experiment at the end of this mail) Issue #2The libsmi examples here^ do not call smiExit():^ https://www.ibr.cs.tu-bs.de/projects/libsmi/example.html^ https://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html Details of the memory leak:To investigate this issue, first noted by 'tcpdump' project, I wrote two simple programs; one calls smiExit(), and the other does not.(Platform: Fedora Core 23 (64 bit)) The following sample program does not call smiExit();$ cat libsmi_noexit.c #include <smi.h> void main(){ smiInit(NULL);} Relevant parts of Valgrind Output:==10291== HEAP SUMMARY:==10291== in use at exit: 3,834 bytes in 45 blocks==10291== total heap usage: 45 allocs, 0 frees, 3,834 bytes allocated ==10291== LEAK SUMMARY:==10291== definitely lost: 80 bytes in 1 blocks==10291== indirectly lost: 0 bytes in 0 blocks==10291== possibly lost: 0 bytes in 0 blocks==10291== still reachable: 3,754 bytes in 44 blocks==10291== suppressed: 0 bytes in 0 blocks The following sample program calls smiExit();$ cat libsmi_exit.c#include <smi.h> void main(){ smiInit(NULL); smiExit();} Relevant parts of Valgrind Output:==10299== HEAP SUMMARY:==10299== in use at exit: 80 bytes in 1 blocks==10299== total heap usage: 45 allocs, 44 frees, 3,834 bytes allocated==10299== ==10299== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1==10299== at 0x4C2A988: calloc (vg_replace_malloc.c:711)==10299== by 0x4E48A9D: smiMalloc (in /usr/lib64/libsmi.so.2.0.27)==10299== by 0x4E448E5: smiInitData (in /usr/lib64/libsmi.so.2.0.27)==10299== by 0x4E4B8B2: smiInit (in /usr/lib64/libsmi.so.2.0.27)==10299== by 0x4006F3: main (in /home/bijal/projects/libsmi_leaktest/libsmi_exit) ==10299== LEAK SUMMARY:==10299== definitely lost: 80 bytes in 1 blocks ==10299== indirectly lost: 0 bytes in 0 blocks==10299== possibly lost: 0 bytes in 0 blocks==10299== still reachable: 0 bytes in 0 blocks==10299== suppressed: 0 bytes in 0 blocks` I have just begun to contribute to tcpdump project, and have no experience of using libsmi,but glad to participate in discussion with regards to this. ThanksBijal

2 3

smiExit() fails to free one allocation ?
by Bijal Thanawala 28 Jul '16

28 Jul '16

[Apology! Re-sending as plain text. Please ignore the earlier ill-formatted html mail] Hi libsmi team, This is to report two issues with regards to : libsmi-0.4.8-16.fc23.x86_64 Issue #1 Although smiExit() does good job of freeing memory blocks allocated by smiInit it misses one. To be precise, 44 out of 45 allocated memory block are freed. (Details of the experiment at the end of this mail) Issue #2 The libsmi examples here^ do not call smiExit(): ^ https://www.ibr.cs.tu-bs.de/projects/libsmi/example.html ^ https://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html Details of the memory leak: To investigate this issue, first noted by 'tcpdump' project, I wrote two simple programs; one calls smiExit(), and the other does not. (Platform: Fedora Core 23 (64 bit)) The following sample program does not call smiExit(); $ cat libsmi_noexit.c #include <smi.h> void main() { smiInit(NULL); } Relevant parts of Valgrind Output: ==10291== HEAP SUMMARY: ==10291== in use at exit: 3,834 bytes in 45 blocks ==10291== total heap usage: 45 allocs, 0 frees, 3,834 bytes allocated ==10291== LEAK SUMMARY: ==10291== definitely lost: 80 bytes in 1 blocks ==10291== indirectly lost: 0 bytes in 0 blocks ==10291== possibly lost: 0 bytes in 0 blocks ==10291== still reachable: 3,754 bytes in 44 blocks ==10291== suppressed: 0 bytes in 0 blocks The following sample program calls smiExit(); $ cat libsmi_exit.c #include <smi.h> void main() { smiInit(NULL); smiExit(); } Relevant parts of Valgrind Output: ==10299== HEAP SUMMARY: ==10299== in use at exit: 80 bytes in 1 blocks ==10299== total heap usage: 45 allocs, 44 frees, 3,834 bytes allocated ==10299== ==10299== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==10299== at 0x4C2A988: calloc (vg_replace_malloc.c:711) ==10299== by 0x4E48A9D: smiMalloc (in /usr/lib64/libsmi.so.2.0.27) ==10299== by 0x4E448E5: smiInitData (in /usr/lib64/libsmi.so.2.0.27) ==10299== by 0x4E4B8B2: smiInit (in /usr/lib64/libsmi.so.2.0.27) ==10299== by 0x4006F3: main (in /home/bijal/projects/libsmi_leaktest/libsmi_exit) ==10299== LEAK SUMMARY: ==10299== definitely lost: 80 bytes in 1 blocks ==10299== indirectly lost: 0 bytes in 0 blocks ==10299== possibly lost: 0 bytes in 0 blocks ==10299== still reachable: 0 bytes in 0 blocks ==10299== suppressed: 0 bytes in 0 blocks` I have just begun to contribute to tcpdump project, and have no experience of using libsmi, but glad to participate in discussion with regards to this. Thanks Bijal

1 0

[PATCH] smidiff: dont rely on udefined behavior
by Wouter van Kesteren 10 Feb '16

10 Feb '16

>From man sprintf: NOTES Some programs imprudently rely on code such as the following sprintf(buf, "%s some further text", buf); to append text to buf. However, the standards explicitly note that the results are undefined if source and destination buffers overlap when calling sprintf(), snprintf(), vsprintf(), and vsnprintf(). Depending on the version of gcc(1) used, and the compiler options employed, calls such as the above will not produce the expected results. On my system with gcc-5.3, glibc-2.22 this makes the tests on 0.4.8 fail. With this patch the tests pass. This patch is also applicable to 0.5.0, however the testsuite of 0.5.0 fails with: 116,118c122,123 < ../../mibs/ietf/IF-MIB:1741 warning: legal status change from `current' to `deprecated' for `ifCompliance' < ../../mibs/ietf/IF-MIB:1741 warning: description of MODULE-COMPLIANCE `ifCompliance' changed < ./IF-MIB.old:1244 info: previous definition of `ifCompliance' --- > ./IF-MIB.old:1244 compliance `ifCompliance' has been deleted > ../../mibs/ietf/IF-MIB:1741 warning: compliance `ifCompliance' has been added So consider this email both a patch, and a bugreport. --- tools/smidiff.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/tools/smidiff.c b/tools/smidiff.c index dcd2166..c94a143 100644 --- a/tools/smidiff.c +++ b/tools/smidiff.c @@ -941,15 +941,17 @@ getStringRange(SmiType *smiType) SmiRange *range; int i; char *str, *subRange; + size_t strLen; str = NULL; for(i = 0, range = smiGetFirstRange(smiType); range; i++, range = smiGetNextRange(range)) { if (i) { - str = realloc( str, strlen( str ) +2 ); + strLen = strlen( str ); + str = realloc( str, strLen +2 ); if( str ) { - sprintf(str, "%s|", str); + sprintf(str + strLen, "|"); } } @@ -961,16 +963,18 @@ getStringRange(SmiType *smiType) if( !subRange ) { return NULL; } - str = realloc( str, strlen( str ) + strlen( subRange ) + 1 ); + strLen = strlen( str ); + str = realloc( str, strLen + strlen( subRange ) + 1 ); if( !str ) { return NULL; } - sprintf( str, "%s%s", str, subRange ); + sprintf( str + strLen, "%s", subRange ); } - str = realloc( str, strlen( str ) + 2 ); + strLen = strlen( str ); + str = realloc( str, strLen + 2 ); if( str ) { - sprintf(str, "%s)", str); + sprintf(str + strLen, ")"); } return str; } @@ -1613,6 +1617,7 @@ getStringIndexList( SmiNode *smiNode ) SmiNode *indexNode; SmiElement *smiElement; char *strIdxLst; + size_t strIdxLstLen; smiElement = smiGetFirstElement( smiNode ); indexNode = smiGetElementNode( smiElement ); @@ -1623,10 +1628,11 @@ getStringIndexList( SmiNode *smiNode ) smiElement = smiGetNextElement( smiElement ); while ( smiElement ) { indexNode = smiGetElementNode( smiElement ); + strIdxLstLen = strlen( strIdxLst ); strIdxLst = (char *)realloc( strIdxLst, - strlen( strIdxLst ) + + strIdxLstLen + strlen( indexNode->name ) + 4 ); - sprintf( strIdxLst, "%s, `%s'", strIdxLst, indexNode->name ); + sprintf( strIdxLst + strIdxLstLen, ", `%s'", indexNode->name ); smiElement = smiGetNextElement( smiElement ); } return strIdxLst; -- 2.7.0

2 1

Enterprises part empty
by Yves Desgagne 12 May '15

12 May '15

Hi, I’m using libsmi or to be more accurate smidump to generate a Python dictionaries represention of the MIB module later used by the Ruby SNMP gem. The following command is working well on my Mac. smidump -k -f python SIMPLER-NETWORKS-MIB.my The output is in the form of: sni: 1.3.6.1.4.1.4987 ezedge: 1.3.6.1.4.1.4987.1 sniConnTable: 1.3.6.1.4.1.4987.1.1 sniConnEntry: 1.3.6.1.4.1.4987.1.1.1 ... But I’m not deploying the Rails app to my Mac. I have to deploy that on an Ubuntu server. I installed libsmi and smidump using apt-get packages. But when I run the exact same command to generate the output, I get the following: sni: '0.4987' ezedge: 0.4987.1 sniConnTable: 0.4987.1.1 sniConnEntry: 0.4987.1.1.1 All the entreprise part is shown as 0 instead of the correct number. So the Ruby gem is actually not able to access anything. Any idea how to fix that? Thanks, Yves

2 1

Null pointer dereference in parser-smi.y
by Tomalak Geret'kal 16 Apr '15

16 Apr '15

Hi I've been trying to build libsmi trunk for x86_64-w64-mingw32 and I've encountered a problem. I don't know whether the MIB I'm trying to load has some invalidity, though it's a CISCO MIB and smilint accepts it. Presumably I have done something wrong elsewhere and will look into that separately. Regardless, the particular segfault I received led me to this code (lib/parser-smi.y:2420), which seems strange: if (!($11)) smiPrintError(thisParserPtr, ERR_INTERNAL); /* * Otherwise, we have to allocate a * new Type struct, inherited from $10. */ $$ = duplicateType($11, 0, thisParserPtr); duplicateType (lib/smi-data.c:2404) unconditionally dereferences its first parameter so, since $11 is invalid in this block, the call to duplicateType is broken. What is this code supposed to be instead? Best regards Tom

2 4

libsmi 0.5.0
by Vincent Bernat 03 Nov '14

03 Nov '14

Hi! I just noticed that libsmi 0.5.0 has been released last month but I didn't see any announce here. The changelog being quite verbose is there a short version with major changes (if there is any major change)? Thanks! -- Use debugging compilers. - The Elements of Programming Style (Kernighan & Plauger)

3 2

Display-hint based value formatting
by Shawn J. Goff 18 Jul '14

18 Jul '14

I'm trying to figure out if there is a way to print the value as specified by the display hint. There is an item on the TODO page that says "split the library into [t]wo layers: (a)[...](b)[...]display-hint based value formatting". This sounds like it is something the library already does; should I keep looking, or is it not in there? Thanks, -- Shawn J. Goff | Accelerated | Systems Engineer | 813.699.3107

2 1

smidump generating invalid XML output for RFC1158 mib
by Peter Postma 17 Dec '13

17 Dec '13

Dear list users, I am trying to dump a MIB to XML using smidump (v0.4.8) but the output provides invalid XML. The MIB in question is: http://www.snmplink.org/OnLineMIB/Standards/index.html#124 (RFC1158-MIB, "rfc 1158 MIB-II.mib"). Some sources do have syntax errors (like missing comma's) which I corrected in the source file already. The XML output from smidump however is invalid XML. It generates the following XML e.g.: ------------------------ <table name="ipNetToMediaTable" oid="1.3.6.1.2.1.4.22" status="mandatory"> <description> ... </description> <row name="ipNetToMediaEntry" oid="1.3.6.1.2.1.4.22.1" status="mandatory"> <linkage> </linkage> <description> ... </description> <scalar name="ipNetToMediaIfIndex" oid="1.3.6.1.2.1.4.22.1.1" status="mandatory"> ------------------------ As can be seen in this example, the <row> tag is never closed and neither is the <table> tag. This is not the only occurance though and happends several times in this same file. This means I can not parse the XML output and also means I'm missing data. Is this a known bug? Is there a workaround? Or am I doing something wrong? With kind regards, Peter Postma

3 5