Libsmi

libsmi@ibr.cs.tu-bs.de

579 discussions

Maintaining https://gitlab.ibr.cs.tu-bs.de/nm/libsmi
by Marek Hajduczenia 04 Apr '24

04 Apr '24

Good afternoon, Libsmi distro I have code to contribute to the libsmi library. During the development of one of IEEE 802.3.1 standard revisions, a need for the configurable control of the line width became apparent to reprint existing MIBs into a line-width controlled format (via smidump). The parameter controlling the line width is hard coded right now so I have extended the existing parameter set with -w (--width) parametrization, which allows to set the line width for multiline printing function. I also had to rewrite the multiline printing function to properly account for whole word delimiters to provide a more visually acceptable output. I have modified code available for review (there are in total 5-6 files I had to touch). The code is written in C and compiled on Ubuntu 22.04 with all latest libraries for test purposes. What would be the best way to share the code, have it reviewed, and perhaps pulled into the GIT repository? My goal, at the end of the day, is to make sure that the updated code with -w parameter support is included in future Linux distros, to facilitate SMIv2 code development for folks. Regards Marek Hajduczenia

1 0

C99 compatibility fixes
by Florian Weimer 14 Apr '23

14 Apr '23

libsmi 0.4.8 in Fedora needs the attached patches to keep building with future compilers that are more strict regarding the C99 language version. Related to: <https://fedoraproject.org/wiki/Changes/PortingToModernC> <https://fedoraproject.org/wiki/Toolchain/PortingToModernC> Thanks, Florian

1 0

RFC-1212 inclusion in libsmi
by Nathan Ward 25 Jan '22

25 Jan '22

Hi, RFC-1212 includes some examples. These examples have been included as part of libsmi along with other MIBs, presumably as a result of smistrip or similar. My belief is that it should not be included - as RFC-1212 is only examples. Would you accept a patch removing RFC-1212 from libsmi? -- Nathan Ward

2 1

Subversion server down?
by Gerald Combs 15 Jan '21

15 Jan '21

Hi, I'm attempting to check out the libsmi SVN trunk, but unfortunately the server appears to be down: $ svn co http://svn.ibr.cs.tu-bs.de/software-ibr-1999-libsmi/trunk libsmi svn: E170013: Unable to connect to a repository at URL 'http://svn.ibr.cs.tu-bs.de/software-ibr-1999-libsmi/trunk' svn: E120108: Error running context: The server unexpectedly closed the connection. $ curl -I http://svn.ibr.cs.tu-bs.de/software-ibr-1999-libsmi curl: (7) Failed to connect to svn.ibr.cs.tu-bs.de port 80: Connection refused

3 3

Insufficient buffer length in getStringIndexList() in smidiff.c
by Nathan Kitchen 07 Jan '19

07 Jan '19

In smidiff.c, in the function getStringIndexList(), the realloc() call for strIdxList adds 4, which matches the number of literal characters in the format string in the subsequent sprintf() call, but it doesn't account for the terminating null byte. It should be "+ 5". I suspect that most runs of smidiff don't get memory corruption from the buffer overrun because realloc() usually happens to allocate a memory block larger than requested (e.g., the next larger power of 2). -- Nathan

2 1

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

Jump to page:

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