Libsmi May 2008

libsmi@ibr.cs.tu-bs.de

3 participants
5 discussions

libsmi numeric constraints convertion bug
by Ilya Etingof 24 Nov '08

24 Nov '08

I've run into a possible problem in SVN version of libsmi. I have not done any debugging, so this is just a bug report: When I do: smidump -f python TCP-MIB.txt for the following MIB text: tcpMaxConn OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1." ::= { tcp 4 } smidump generates: "tcpMaxConn" : { "nodetype" : "scalar", "moduleName" : "TCP-MIB", "oid" : "1.3.6.1.2.1.6.4", "status" : "current", "syntax" : { "type" : { "basetype" : "Integer32", "ranges" : [ { "min" : "-1", "max" : "2147483647" }, ], "range" : { "min" : "4294967295", "max" : "2147483647" }, }, }, "access" : "readonly", "description" : """ [skipped] """, }, # scalar Where range constraints seem to be broken at: 1. Range minimum (0) gets converted into 4294967295. 2. Single value constraint (-1) gets translated into a value range constraint with wildly inflated upper range (2147483647). Current stable release (0.4.5) behaves differently (yet, incorrectly) in this respect: "tcpMaxConn" : { "nodetype" : "scalar", "moduleName" : "TCP-MIB", "oid" : "1.3.6.1.2.1.6.4", "status" : "current", "syntax" : { "type" : { "basetype" : "Integer32", "range" : { "min" : "-1", "max" : "2147483647" }, }, }, "access" : "readonly", "description" : """ [skipped] """, }, # scalar Is there currently a fix for this issue? Thanks, ilya

2 17

64bit cleanliness of libsmi
by Alex Bennee 21 May '08

21 May '08

Hi, This has come up before [1] but I'm not entirley convinced that libsmi is 64 bit clean. I've been using OpenNMS's mib2opennms[2] which uses libsmi and it fails badly on my 64 bit platform but works fine on a 32 bit one. The failure is basically a failure to validate the MIB ( (smiModule->conformance) && (smiModule->conformance < 3 ) followed by a core dump in libsmi. Running with valgrind shows: ==30684== Invalid read of size 8 ==30684== at 0x4E3EBF3: getNextChildObject (smi.c:163) ==30684== by 0x4E40BEB: smiGetFirstNode (smi.c:1387) ==30684== by 0x4011D0: dumpXml (mib2opennms.c:102) ==30684== by 0x4019B1: main (mib2opennms.c:296) ==30684== Address 0x5434E00 is 64 bytes inside a block of size 80 free'd ==30684== at 0x4C20A6E: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30684== by 0x4E3CDA8: smiFree (util.c:133) ==30684== by 0x4E375B9: freeNodeTree (data.c:4306) ==30684== by 0x4E385AE: loadModule (data.c:4740) ==30684== by 0x4E3F5AA: smiLoadModule (smi.c:416) ==30684== by 0x401811: main (mib2opennms.c:261) ==30684== Which seems to indicate something has gone wrong inside libsmi. As far as I can tell the mib2opennms tool is calling the API correctly, it just seems part of the MIB tree are free'ed before use. I've been poking around the code and the first thing that jumped out at me was: /* misc mappings of SMI types to C types */ typedef char *SmiIdentifier; typedef unsigned long SmiUnsigned32; typedef long SmiInteger32; Because sizeof(long) == 8 on x86_64. However I'm unsure how this would cause the breakage I'm seeing. The "make check" target fails two tests (smidump-sming.test & smidump-cm.test) but the previous thread [1] seemed to imply these where out dated tests. Any suggestions on how I could proceed debuging would be appreciated. [1] http://mail.ibr.cs.tu-bs.de/pipermail/libsmi/2006-March/000836.html [2]https://opennms.svn.sourceforge.net/svnroot/opennms/mib2opennms/trunk/ -- Alex Bennee Software Engineer, Cambridge Broadband

1 0

RE: [libsmi] Windows Context - No config.nmake file
by Greg Roberts 20 May '08

20 May '08

I have vc8 , vc9 ... Just thought with makefile technology, the older the better Thanks for the help Once I get it working I can add : - some source dir option -s "path" - use of ./ in front of file if the initial opened How things get back into the system is another story. Regards Greg Roberts wrote: > Thanks for your help. I could let you have a copy of my binaries, built with MSVC8, for which you would need the MSVC8 redistrib package from M$. They are built based at c:\usr\local > I have placed files in the c:\smi dir and think I have most things > correct in the config.nmake. however whatever argument I place on nmake > still says > It does not know how to make the first item in LIBSMIOBJS in "makefile" It is not not a good idea to build in the target directory. You would be better off building in say c:\libsmi and letting "nmake install" put everything in the right place. Assuming you are going to use c:\smi as the target, there are only a couple of things in config.nmake that should need fiddling. MSC_VARIANT is the main one. The other is ENABLE_LIBSMI_DLL if you want to build the DLL. config.h needs the paths fixed as I said before. > > Env var > Path=c:\smi\bin;C:\Perl\bin\;C:\Program Files\Debugging Tools for > Windows; .......... > > ================================= > > C:\smi\win>nmake > > Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > NMAKE : fatal error U1073: don't know how to make '..\temp\win.obj' > Stop. > > ========================== > > regards > > -----Original Message----- > From: Andrew Hood [mailto:ajhood@fl.net.au] > Sent: Monday, 19 May 2008 9:36 PM > To: Greg Roberts > Cc: libsmi(a)ibr.cs.tu-bs.de > Subject: Re: [libsmi] Windows Context - No config.nmake file > > Greg Roberts wrote: > >>I have downloaded libsmi-0.4.8.tar.gz and this has no config.nmake >>(trying to build on windows) >> >>A thread exists in april 2008 but does not reference how to get a copy >>of the file. > > > I'd recommend you get the source from the SVN repository. It looks like > libsmi-0.4.8.tar.gz is missing a couple of things, including > config.nmake. > > >>>>Does anyone have a working vc6 DSP / DSW file set ? > > > No-one I know of builds with the IDE. Customize config.nmake and > config.h for your environment, then run nmake. > > >>Now I might not need to create a fresh binary if I can get around this >>issue ... >> >>Smidump.exe will not find the referenced MIB files, e.g. > > > The default file location on windows is under c:\smi and config.h has > unix style dir seps. e.g. > > #define DEFAULT_GLOBALCONFIG "c:/smi/smi.conf" > #define DEFAULT_SMIPATH > "c:/smi/mibs/ietf;c:/smi/mibs/iana;c:/smi/mibs/irtf;c:/smi/mibs/site;c:/ > smi/mibs/tubs" > > That works with mingw but I have no luck with MSVC: > > #define DEFAULT_GLOBALCONFIG "c:\\smi\\smi.conf" > #define DEFAULT_SMIPATH > "c:\\smi\\mibs\\ietf;c:\\smi\\mibs\\iana;c:\\smi\\mibs\\irtf;c:\\smi\\mi > bs\\site;c:\\smi\\mibs\\tubs" > > Running: > > nmake > nmake install > > should put everything in the right place > > >>I even added this directory into the system PATH value. > > > Assuming the above file locations you could add "c:\smi\bin" to the PATH > > If you want to build the DLL in config.nmake: > > ENABLE_LIBSMI_DLL=USE > > and run: > > nmake clean > nmake smi.dll > nmake > -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

1 0

Windows Context - No config.nmake file
by Greg Roberts 19 May '08

19 May '08

I have downloaded libsmi-0.4.8.tar.gz and this has no config.nmake (trying to build on windows) A thread exists in april 2008 but does not reference how to get a copy of the file. >> Does anyone have a working vc6 DSP / DSW file set ? Now I might not need to create a fresh binary if I can get around this issue ... Smidump.exe will not find the referenced MIB files, e.g. Smidump -f smiv1 ./test-MIB Comes up with errors that it cannot find the referenced files, e.g. SNMPv2-SMI . I have copied all files into the same Directory as the .exe. I even created a shortcut forcing the current directory to where smidump.exe. I even added this directory into the system PATH value. The problem seems to be that "test-mib" is not found, but "./test-mib" is. So when it goes to find the other files the same problem occurs. >> How does one get around this issue ? Further background was I was trying to see if I could convert some v2 MIBs to v1.. Many thanks !! Greg Roberts ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 1

Patches to build generated files on Windows
by Anders Broman 04 May '08

04 May '08

WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact MIMEDefang Administrator <admin(a)ibr.cs.tu-bs.de>. For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named make_errormacros.sh was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. Hi, I have been trying to build the generated files on windows using Cygwin Flex and Bison (avoiding the autogen stuff) and I think I'm almost there The makefile patch can be checked in if you think this is ok, currently the makefile in ../lib is not called from there. Make_errormacros does not produce a vallid errormacros.h ( I don't know why I copied it from makefile.in) The result is #define { 0, ERR_INTERNAL, "internal", 0 #define { 0, ERR_MAX_LEX_DEPTH, "import-depth", 1 : Instead of: #define ERR_INTERNAL 0 #define ERR_MAX_LEX_DEPTH 1 I think the makefile.nmake and make_errormacros.sh can be checked in in ../lib/ and continue to be worked on there. Possibly the stuff related to errormacros can be removed for the time beeing. Is this route worth persuing or are you happy with things as they are? <<make_errormacros.sh>> <<makefile.nmake>> <<makefile.patch.txt>> Regards Anders

2 3

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 2008