June 2011 - Libsmi - lists.ibr.cs.tu-bs.de

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

Invitation to connect on LinkedIn
by Pete Wilson 10 Jun '11

10 Jun '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Pete Pete Wilson Contract software engineer at www.pwilson.net Greater Boston Area Confirm that you know Pete Wilson https://www.linkedin.com/e/-sqf3rv-gorc5ofi-6j/isd/3175146899/dgUlWFDb/ -- (c) 2011, LinkedIn Corporation

1 0