Libsmi July 2001

libsmi@ibr.cs.tu-bs.de

13 participants
13 discussions

RE: [libsmi] Files to move
by Norseth, KC 07 Aug '01

07 Aug '01

It worked fine in that it created the programs and such in the work directory I was working in. All the subdirectories were made, the compiles worked, and the install tests were done. After testing the programs myself to make sure they worked, I tried to move only the relavent files into the bin directory where everyone goes to. The smilint script tries to call the smilint program from the wrong directory. I am missing something on how to get it to point the correct directory. I did move the .libs directory also under the bin, but that did not help. |-----Original Message----- |From: Keith Dart [mailto:kdart@kdart.com] |Sent: Thursday, July 26, 2001 2:41 PM |To: Norseth, KC |Cc: 'libsmi(a)ibr.cs.tu-bs.de' |Subject: Re: [libsmi] Files to move | | |On Thu, 26 Jul 2001, Norseth, KC wrote: | |> I have compiled the libsmi software on my sun box and things |run fine when I |> reference the programs where I compiled them. I now need to |move the files |> into a production directory for all to be able to use. What |> files/directories do I need to move to make this work and if |I need to |> modify a config file, which ones? |> |> K.C. | |"make install" does not work for you? | | | \\|// | (O O) |-- |--------------------oOOo~(_)~oOOo------------------------------ |---------- |Keith Dart |<mailto:kdart@kdart.com> |<http://www.kdart.com/> |--------------------------------------------------------------- |------------- |Ever since my brain transplant I ... |=============================================================== |============= |

2 1

getting modules in a file
by Keith Dart 07 Aug '01

07 Aug '01

Hello all, I have some MIB files that actually define multiple modules in one file. I would like to retrieve these modules, and only these modules. Currently, If I load the file and get all the modules with getFirstModule/getNextModule I also get all of the modules that were imported by this file (which is a lot). Is there any way to get only the defined modules in a single file? Thanks. \\|// (O O) -- --------------------oOOo~(_)~oOOo---------------------------------------- Keith Dart <mailto:kdart@kdart.com> <http://www.kdart.com/> ---------------------------------------------------------------------------- Ever since my brain transplant I ... ============================================================================ -- !! 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.

2 2

Files to move
by Norseth, KC 26 Jul '01

26 Jul '01

I have compiled the libsmi software on my sun box and things run fine when I reference the programs where I compiled them. I now need to move the files into a production directory for all to be able to use. What files/directories do I need to move to make this work and if I need to modify a config file, which ones? K.C.

2 1

Re: [libsmi] libsmi leaks heavily on Win32
by Bill Fenner 19 Jul '01

19 Jul '01

I linked libsmi with dmalloc on UNIX, and it reports leaks too, but it reports them almost all in util.c . These patches allow util.c to work with dmalloc to report the actual allocating line -- since they rely on dmalloc internals, they might not be as portable as the existing HAVE_DMALLOC_H code. I might get a chance to look at the results next week, but I figured I'd share the patch in case anyone else wants to do some debugging before then. Bill

1 0

libsmi leaks heavily on Win32
by Deshmukh, Abhay 18 Jul '01

18 Jul '01

Hello all, I downloaded libsmi v 0.2.16 from "http://www.ibr.cs.tu-bs.de/projects/libsmi/" and compiled it under win32 using VC++6 using the makefile provided in the "win" subdir. To find possible memory leaks I included: #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> at the beginning and: _CrtDumpMemoryLeaks(); // just before return 0; in main() at the end of "smidump.c" Secondly, I uncommented #DEBUG in the win\makefile and added /MLd (single-threaded debug) DEBUG = -W3 -Zi -Od /Yd /MLd Finally I ran smidump.exe on rfc1213-mib and this resulted in huge number of memory leaks: Detected memory leaks! Dumping objects -> {2579} normal block at 0x0050E8C8, 5 bytes long. Data: <snmp > 73 6E 6D 70 00 {2563} normal block at 0x0050E268, 5 bytes long. Data: <snmp > 73 6E 6D 70 00 {2559} normal block at 0x0050E188, 8 bytes long. Data: <Counter > 43 6F 75 6E 74 65 72 00 {2555} normal block at 0x0050DFB8, 5 bytes long. Data: <snmp > 73 6E 6D 70 00 ... // lots more I suspect that there is a leak for every single MIB object (not sure). Is anyone aware of this ? This is pretty severe for applications which stay permanently in memory and have to compile SMI files on a regular basis. Abhay Deshmukh Sr. Development Engineer BarcoNet Private Limited Tidel Park Module #0305 Taramani, Chennai 600 113. INDIA. Tel +91 44 2540601/02/03/04 ext 205 Fax +91 44 2540605 Mailto : abhayanil.deshmukh(a)barconet.com -- !! 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

Antwort: Re: [libsmi] Fwd: Re: [PATCH] sturcture name change.
by Frank Fock 17 Jul '01

17 Jul '01

Hi, Sorry for not being able to quote, but Lotus Notes is against it :-( In my opinion, a SMI parser that is used to gain information from a MIB module should be as strict as a SMI parser that for checking a MIB module. I will below explain why. Today many of the private MIBs are not usable. May be there is some parser somewhere that is able to parse such broken MIBs but what does the enduser gain? Would you want a lenient compiler for a programming language? Would a program compiled with such a lenient compiler be stable? It is the same with MIB files! We have had so many problems with broken MIBs in the past that we decided to implement a new parser with strict syntax checking that cannot be disabled by option. This is what the majority of our customers embraced, because they had a problem each time a vendor gave them a new MIB to determine whether the MIB will be usable out in the field. The ENDUSER has the problem that something with the network management system does not work and he does not know why. Is this any better than getting an error message that can be used to solve the problem (either by the enduser or by the author of the MIB)? If we do not have strict syntax checking that cannot be turned off the vendors will always say "It's working for us!" and they will keep shifting the problem to the enduser. Regards, Frank |--------+-----------------------> | | Harrie | | | Hazewinkel | | | <harrie@coval| | | ent.net> | | | | | | 16.07.01 | | | 19:58 | | | | |--------+-----------------------> >----------------------------------------------------------------------------| | | | An: Juergen Schoenwaelder <schoenw(a)ibr.cs.tu-bs.de> | | Kopie: D.T.Shield(a)csc.liv.ac.uk, strauss(a)ibr.cs.tu-bs.de, | | libsmi(a)ibr.cs.tu-bs.de, (Blindkopie: Frank Fock/MAIN/MC1) | | Thema: Re: [libsmi] Fwd: Re: [PATCH] sturcture name change. | >----------------------------------------------------------------------------| Juergen Schoenwaelder wrote: [snip] > > I have a strong opinion about this: Broken MIBs should be rejected. I think this is more an academic/perfect world view. NET-SNMP will be used in conjunction of MIB modules shipped by vendors. These vendors are not using NET-SNMP and their customers are using UCD-SNMP without their knowledgde. Now these customers upgrade to NET_SNMP and everything breaks, because of the broken MIB module. Yes, I agree the vendors need to improve their MIB modules. But in real life the customer has a problem directly. > I agree that libsmi could be improved to recover more gracefully in > some cases. And this is what I heard Frank saying as well. But adding > code to accept modules that for example mix SMI versions is definitely > not the direction I want to go. I agree, that is just an example. Even though, my own MIB compiler is flexible with this. > > We are facing the following situation: > > (a) There are so many broken MIB because so many lenient parsers do > accept them. > (b) There are so many lenient parsers that accept broken MIBs because > there are so many broken MIBs. > > This circular logic needs to be broken up. And the way to do this is > to provide people with good parsers that help them to fix the broken > modules. Yes, it will not be without pain for everyone. But in the > longer term, there will be clear benefits. I am sure all vendors will agree, but that they fix the problem. The bigger problem is taht sometimes MIB modules are already shipped. There is also another view of this. Libsmi as such is currently focussed on parsing and testing MIB modules for there syntactical and semantical correctness. Usage of libsmi inside NET-SNMP is I beleive different. It is there focussed on getting more knowledge of the managed objects at the manager side. I beleive that the resulting libsmi need to be that when used as parser/tester it should reject broken MIB modules and when used inside applications it should attempt as much error recovery as possible. After the error recovery it still may provide all problems of the MIB module, but the application may start using it. Correct me if I am wrong Dave, but I beleive you are looking for something like this too. Harrie -- address: Covalent Technologies, 645 Howard St, San Francisco, CA - 94105 phone: +1-415-536-5221 fax:+1-415-536-5210 personal website: http://www.lisanza.net/ -- !! 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. -- !! 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.

2 1

Fwd: Re: [PATCH] sturcture name change.
by David T. Perkins 16 Jul '01

16 Jul '01

HI, FYI...in case you missed seeing this. >X-Mailer: exmh version 2.0.2 >To: Harrie Hazewinkel <harrie(a)covalent.net> >Cc: net-snmp-coders(a)lists.sourceforge.net >Subject: Re: [PATCH] sturcture name change. >From: Dave Shield <D.T.Shield(a)csc.liv.ac.uk> >Sender: net-snmp-coders-admin(a)lists.sourceforge.net >X-BeenThere: net-snmp-coders(a)lists.sourceforge.net >X-Mailman-Version: 2.0.5 >List-Help: <mailto:net-snmp-coders-request@lists.sourceforge.net?subject=help> >List-Post: <mailto:net-snmp-coders@lists.sourceforge.net> >List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/net-snmp-coders>, > <mailto:net-snmp-coders-request@lists.sourceforge.net?subject=subscribe> >List-Id: A list for net-snmp developers to converse over <net-snmp-coders.lists.sourceforge.net> >List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/net-snmp-coders>, > <mailto:net-snmp-coders-request@lists.sourceforge.net?subject=unsubscribe> >List-Archive: <http://lists.sourceforge.net/archives//net-snmp-coders/> >Date: Thu, 12 Jul 2001 11:29:31 +0100 > > >> I've occasionally had some problems with libSMI objecting to >> some of the UCD-provided MIB files. The effect of this being >> that the MIB initialisation fails, and the UCD tools refuse to >> run (without saying anything, of course). > >I've just been bitten by this again, and investigated in more >detail. The problem appears to lie with the severely cut-down >version of SNMPv2-SMI that we've traditionally shipped. > This is missing a number of core definitions, that were built >into our parser, but libSMI is expecting to find here. >If you copy the 'normal' version of SNMPv2-SMI into place, then >the library seems happy. > > > >As a placeholder, in case anyone wants to investigate *exactly* >what's going wrong - the problem bites at line 645 of SNMPv2-TC. >This is where the Textual Convention "TimeStamp" is being defined, >using the base type "TimeTicks" from SNMPv2-SMI (which is missing >from our version). > libSMI recognises this error, and calls 'printError' to display > unknown type `TimeTicks' > >But shortly after this, it calls 'printError' again, with a >(fatal) 'internal error' - at which point it bombs out. > >This appears to correspond to > > typeDeclarationRHS: TEXTUAL_CONVENTION > >block (lines 1719ff of parser-smi.y in my version) which includes: > > if (($10) && !($10->export.name)) { > /* > * If the Type we found has just been > * defined, we don't have to allocate > * a new one. > */ > $$ = $10; > } else { > if (!($10)) > smiPrintError(thisParserPtr, ERR_INTERNAL); > /* > * Otherwise, we have to allocate a > * new Type struct, inherited from $10. > */ > $$ = duplicateType($10, 0, thisParserPtr); > } > > >It's that ERR_INTERNAL that seems to be the trigger. > >I'm not familiar enough with either libSMI, or yacc/bison, >to offer any suggestions of how this abort could be avoided. > >But a clean copy of the SMI file seems to solve the problem, so >personally, I'm happy to leave it like that (for now, at least). > > >Dave > > >_______________________________________________ >Net-snmp-coders mailing list >Net-snmp-coders(a)lists.sourceforge.net >http://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- !! 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.

5 9

Re: [libsmi] Fwd: Re: [PATCH] sturcture name change.
by Bill Fenner 16 Jul '01

16 Jul '01

If use Dave's MIB and run "SMIPATH=. smilint -l 9 SNMPv2-SMI.txt" the only problem I get is an FYI about {0 0}. That said, this patch adds a smiSetFatalErrorHandler() function which allows a libsmi consumer to set an error handler that gets called before the exit(), which is what I think Dave is asking for. (the error string can be printed into the buffer twice if the normal error reporting level is not too low; however on a fatal error efficiency is not the highest concern =) Bill

1 0

Re: [libsmi] fresh cvs checkout has build problem.
by Bill Fenner 12 Jul '01

12 Jul '01

You need to use GNU Make; automake creates Makefiles that are not compatible with BSD make. Bill -- !! 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.

2 1

fresh cvs checkout has build problem.
by Harrie Hazewinkel 11 Jul '01

11 Jul '01

HI, I just did a fresh cvs checkout of libsmi and the build breaks. $ ./configure ..... $ make make all-recursive Making all in lib "Makefile", line 349: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/harrie/libsmi/libsmi. *** Error code 1 Stop in /usr/home/harrie/libsmi/libsmi. $ It break at the line with -include $(DEP_FILES) this is a generated line. Someone any ideas on how to fix it?? Which version of 'automake' would be needed?? Harrie -- address: Covalent Technologies, 645 Howard St, San Francisco, CA - 94105 phone: +1-415-536-5221 fax:+1-415-536-5210 personal website: http://www.lisanza.net/ -- !! 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.

3 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 July 2001