Libsmi March 2011

libsmi@ibr.cs.tu-bs.de

4 participants
5 discussions

smidump --format=smiv2 output contains some errors in compliance SYNTAX/WRITE-SYNTAX clauses.
by Jens Engel 06 Jun '13

06 Jun '13

Hello, I just stumbled over the following problem in libsmi 0.4.8 and development trunk-tip rev34557 (as of today). The problem resides in the SYNTAX/WRITE-SYNTAX clauses in COMPLIANCE statements. Instead of a "type" the invalid term "(null)" is present. AFFECTED-MIBS (at least): - BRIDGE-MIB - SNMP-VIEW-BASED-ACM-MIB - ... => grep "(null)" *-MIB EXAMPLE: smidump --format=smiv2 BRIDGE-MIB ... OBJECT dot1dStpPriority SYNTAX (null) (0 | 4096 | 8192 | 12288 | 16384 | 20480 | 24576 | 28672 | 32768 | 36864 | 40960 | 45056 | 49152 | 53248 | 57344 | 61440) ... OBJECT dot1dStpPortPriority SYNTAX (null) (0 | 16 | 32 | 48 | 64 | 80 | 96 | 112 | 128 | 144 | 160 | 176 | 192 | 208 | 224 | 240) BUT: Original BRIDGE-MIB that is distributed w/ libsmi contains: OBJECT dot1dStpPriority SYNTAX Integer32 (0 | 4096 | 8192 | 12288 | 16384 | 20480 | 24576 | 28672 | 32768 | 36864 | 40960 | 45056 | 49152 | 53248 | 57344 | 61440) ... OBJECT dot1dStpPortPriority SYNTAX Integer32 (0 | 16 | 32 | 48 | 64 | 80 | 96 | 112 | 128 | 144 | 160 | 176 | 192 | 208 | 224 | 240) smidump --format=smiv2 SNMP-VIEW-BASED-ACM-MIB ... OBJECT vacmViewTreeFamilyMask WRITE-SYNTAX (null) (SIZE(0)) ... SHOULD-BE (as in original MIB distributed with libsmi): ... OBJECT vacmViewTreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE(0)) I assume that smidump does not have the info (only a NULL pointer) and just dumps it as textual info. NOTE: "smidiff <ORIGINAL-MIB> <SMIDUMPED-MIB>" does not seem to show a difference (except warnings, ...). Ciao, Jens

3 2

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

Errors in parse of SNMPv2-SMI and SNMPv2-CONF
by Andrew Hood 25 Mar '11

25 Mar '11

I realise that these aren't ordinary MIBs, but the errors you get when other modules IMPORT from them are probably fixable. SNMPv2-SMI:191: range limit exceeds underlying basetype SNMPv2-SMI:191: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:196: range limit exceeds underlying basetype SNMPv2-SMI:196: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:202: range limit exceeds underlying basetype SNMPv2-SMI:202: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:207: range limit exceeds underlying basetype SNMPv2-SMI:207: range limits must be `lower-bound .. upper-bound' SNMPv2-SMI:217: range limits must be `lower-bound .. upper-bound' lib/parser-smi.y typeTag does not pick up the APPLICATION type, which could then be used to set the correct basetype and ranges. SNMPv2-CONF:4: identifier `ObjectSyntax' cannot be imported from module `SNMPv2-SMI' This one I don't understand. -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who

1 0

Problem with overlapping ranges with the same minimum value
by Göran Runfeldt 24 Mar '11

24 Mar '11

Hello, I have found a problem when using smidump 0.4.8 with certain MIB files. The MIB file from this example is private, so I have extracted the part that causes the problem: TEST-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 Unsigned32, dummyVariable FROM SNMPv2-SMI-v1 ; TestLabel ::= Unsigned32(16..8191|16..1048575) END When using smidump with the SMI or XML output formats (I have not verified the other formats) the process enters an infinite loop. The XML output looks like this: <?xml version="1.0"?>  <smi> <module name="TEST-MIB" language="SMIv1"> </module> <imports> <import module="RFC-1212" name="OBJECT-TYPE"/> <import module="" name="Unsigned32"/> <import module="" name="dummyVariable"/> </imports> <typedefs> <typedef name="TestLabel" basetype="Unsigned32"> <range min="16" max="1048575"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> <range min="16" max="8191"/> ... The last line is repeated infinitely. The problem was identified to be caused by the same minimum value (16) in the two ranges. Smidump correctly warns about overlapping ranges, but this code was added to keep smidump from looping when using the -k option: --- libsmi-0.4.8-old/lib/smi.c 2008-04-18 12:42:50.000000000 +0200 +++ libsmi-0.4.8/lib/smi.c 2011-03-22 16:18:29.000000000 +0100 @@ -867,7 +867,13 @@ if ((!listPtr) || (!listPtr->nextPtr)) { return NULL; } - + + /* Check for duplicate min values in ranges and ignore those ranges + instead of going into an infinite loop. */ + if (!memcmp(&((Range *)listPtr->nextPtr->ptr)->export.minValue, + &smiRangePtr->minValue, sizeof(struct SmiValue))) + return NULL; + return &((Range *)listPtr->nextPtr->ptr)->export; } Any thoughts? //Göran

2 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

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 March 2011