Libsmi November 2010

libsmi@ibr.cs.tu-bs.de

4 participants
4 discussions

Segfault when parsing invalid MIB
by Vincent Bernat 18 Jun '11

18 Jun '11

Hi! On my computer, smilint RMON2-MIB leads to a segfault because, I think, the rmon symbol is not known because of a missing MIB which leads to an incorrect tokenRing symbol. For example, with smiquery: MibNode: TOKEN-RING-RMON-MIB::tokenRing OID: 32395664.0 Declaration: <value-assignment> NodeKind: node I think that the bogus OID is related to the segfault which happens in checkObjects in the loop that should find the parent node which follows an invalid pointer. I have looked around the segfault but every data is corrupted in the core file. Even modulePtr is not correct at all. I have taken this very small MIB : INVALID-MIB DEFINITIONS ::= BEGIN IMPORTS rmon FROM NORFC-MIB; tokenRing OBJECT IDENTIFIER ::= { rmon 10 } END rmon is not solvable and tokenRing is not solvable too. This does not lead to a segfault, but I get bogus OID : Module: INVALID-MIB MibNode: INVALID-MIB::tokenRing OID: 23465424.0 Declaration: <value-assignment> NodeKind: node I have followed the parser step by step (smiparse()). At the exit of this function, parser.modulePtr is correct. The first object is rmon with OID 0 and the second object is tokenRing with OID 0.10. However, after freeNodeTree(), the second object OID becomes 0.0. I did not see any other change. If I comment freeNodeTree() and smiFree() and try again smiquery, I get: Module: INVALID-MIB MibNode: INVALID-MIB::tokenRing OID: 0.10 ParentNode: INVALID-MIB::rmon Declaration: <value-assignment> NodeKind: node Which seems correct. On the real MIB, I get: Module: RFC1155-SMI Module: TOKEN-RING-RMON-MIB MibNode: TOKEN-RING-RMON-MIB::tokenRing OID: 0.10 ParentNode: TOKEN-RING-RMON-MIB::rmon Declaration: <value-assignment> NodeKind: node Which is fine too. However, smilint still segfaults. I have tried to comment other occurrences of the same pattern with no luck. I am not sure to grasp the structures used by the parser but I believe that when there is no way to link a part of the tree, it is freed. Maybe, those nodes should be attached to some fake element in parser-smi.y instead of setting parentPtr to NULL? I have tried to attach them to modulePtr->firstObjectPtr without any luck. Maybe someone can point me in the right direction to get this right? -- GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY -+- Bart Simpson on chalkboard in episode 7G13

1 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

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

lwip
by Volker Goller 06 Nov '10

06 Nov '10

Hi, new to libsmi, asking propably an old question: Anyone working on lwip (Light Weight IP Stack) support for smidump? Mit freundlichen Grüßen, Best Regards, Cordialement, Volker Goller -- * mocom software GmbH & Co KG, Tel: +49-241-902238 * Jülicher Strasse 250 Fax: +49-241-902563 * D52070 Aachen, Germany info(a)mocom-software.de * www.mocom-software.de * * HRA 4221, Registergericht Aachen * Komplementär & Geschäftsführung: * Mocom Software Bet. u. Verw. GmbH, * HRB. 7024, Registergericht Aachen, * Geschäftsführer Volker Goller * Gerichtsstand: Aachen * USt. Id. : DE189 470 867 * * Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte * Informationen. Wenn Sie nicht der richtige Adressat sind oder diese * E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den * Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, die * unbefugte Weitergabe oder Nutzung von Informationen aus dieser Mail * ist nicht gestattet. * * This e-mail may contain confidential and/or privileged information. * If you are not the intended recipient (or have received this e-mail * in error) please notify the sender immediately and destroy this e- * mail. Any unauthorized copying, disclosure, distribution or use of the * material in this e-mail is strictly forbidden. * * $Author: Volker $ * $Date: 2008-11-08 14:32:11 +0100 (Sa, 08 Nov 2008) $ * $Revision: 160 $ *

2 1

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 November 2010