Libsmi November 2009

libsmi@ibr.cs.tu-bs.de

3 participants
3 discussions

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

Handling incomplete/incorrect MIB
by Vincent Bernat 21 Dec '09

21 Dec '09

Hi! When a MIB is incomplete (because for example, there is a missing MIB which should have been imported), it is not possible to retrieve nodes that are not resolvable to an OID (which is good). However, it is still possible to retrieve nodes by their name. For example : $ cat test.mib TEST-MIB DEFINITIONS ::= BEGIN IMPORTS inexistentObject FROM INEXISTENT-MIB; myNode OBJECT IDENTIFIER ::= { inexistentObject 1 } END $ smiquery -p test.mib node TEST-MIB::myNode MibNode: TEST-MIB::myNode OID: 1414743380.1112100141 Declaration: <value-assignment> NodeKind: node The OID is bogus. Sometimes, libsmi will just segfault. If I use smidump, it is able to detect that the MIB is bogus. If I force dump (with -k), it gives me an empty MIB because the bogus node is not added to the list of nodes. smidump detects the problem by looking at "conformance" attribute in smi_module structure. I don't find any documentation about this. Is it the same conformance level as described in smilint(1)? Therefore, if I load a MIB how should I test conformance level? - (module->conformance) && (module->conformance >= 1) - (module->conformance) && (module->conformance > 1) Thanks! -- BOFH excuse #413: Cow-tippers tipped a cow onto the server.

2 2

smidump 0.4.6 crash on Windows ...
by Sandy Walsh 25 Nov '09

25 Nov '09

Hi, I'm trying to parse the NTCIP 1205CCTV mib with v0.4.6 of smidump (to python). This mib is dependent on TMIB-II, RFC1155-SMI, RFC1158-MIB and RFC-1212. My directory structure is like this: ...\1205cctv.mib ...\mibs\RFC1155-SMI.mib ...\mibs\RFC1158-MIB.mib ...\mibs\RFC-1212.mib ...\mibs\TMIB-II.mib and SMIPATH=C:\...\mibs set in my environment. When I run smidump.exe 1205CCTV.mib from the same directory as the 1205mib the program crashes without any other feedback. I've also tried moving all the mibs into the same directory without luck. I've tried removing/slowing introducing each of the above mibs to see if one is troublesome. One message I did get before introducing RFC-1212 was: 1205CCTV.mib:98: object identifier `cctv' defined recursively or too long 1205CCTV.mib:102: object identifier `cctvRange' defined recursively or too long 1205CCTV.mib:107: object identifier `rangeMaximumPreset' defined recursively or too long 1205CCTV.mib:121: object identifier `rangePanLeftLimit' defined recursively or too long 1205CCTV.mib:136: object identifier `rangePanRightLimit' defined recursively or too long 1205CCTV.mib:151: object identifier `rangePanHomePosition' defined recursively or too long 1205CCTV.mib:164: object identifier `rangeTrueNorthOffset' defined recursively or too long 1205CCTV.mib:178: object identifier `rangeTiltUpLimit' defined recursively or too long 1205CCTV.mib:194: object identifier `rangeTiltDownLimit' defined recursively or too long ... on and on ... What might cause this? Any ideas what the cause of the crash might be? I can supply the mibs if you want to try it yourself. Thanks in advance, Sandy

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 2009