Libsmi December 2010

libsmi@ibr.cs.tu-bs.de

3 participants
3 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

question on smiInit...
by Mark Martin 14 Dec '10

14 Dec '10

I have used libsmi for a couple of projects, having said that, the one thing I have discovered in regards to smiInit (this is proven with the sample progam, smiInit takes an argument, or NULL, using NULL, it will not dump the OID tree, except for the first node, then nothing else follows... except the remaining numbers. However, if you put something (doesn't matter what) as a char * argument, the tree parse works. I have looked at the manual page many times, and even looked at the 'C' code for smiInit, and I am not sure of the full functionality of the argument, other than it adds a 'handle' in the init function, all the the man page says is 'tag:dataset' I am not sure what this means in the context it is implemented. Can someone provide more insight, as to how and why someone would used this, by a more practical explanation? I can pass "x", and the parse works, no "x:yyy", so I am not sure what this parameter would be used for other than it actually parsing the mib tree.

3 11

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