July 2006 - Libsmi - lists.ibr.cs.tu-bs.de

libsmi reporting parse error, expecting '$'
by Juergen Schoenwaelder 21 Mar '07

21 Mar '07

Folks, I was getting this error IF-MIB:1: parse error, expecting `$' on several differnt platforms and it finally turned out to be an issue with bison/flex. I do not know the details, but I do know that the combination bison 1.875d and flex 2.5.31 does not work while the combination bison 2.1 and flex 2.5.4 seems to be fine. So if someone runs into similar trouble, make sure you upgrade your build tools... /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany

2 3

More malformed patterns using -f xsd
by Arndt Jonasson 13 Sep '06

13 Sep '06

I use libsmi 0.4.5. When I have a textual convention like this one: 1) NiceString1 ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2)) the pattern which "dumpsmi -f xsd" translates the display hint into is: ((0|[1-9]([0-9]{0,5})) which has unbalanced parentheses. I think that line 655 smiAsprintf( &ret, "%s(0|[1-9]([0-9]{0,%d})", should be smiAsprintf( &ret, "%s(0|[1-9]([0-9]{0,%d}))", 2) Similar problem here: NiceString2 ::= TEXTUAL-CONVENTION DISPLAY-HINT "4d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (0..2 | 4..5)) The pattern: (((0|[1-9]([0-9]{0,5}))|((0|[1-9]([0-9]{0,10}))) I think that line 726 if( ! lengths[ i - 2 ] ) { should be if( ! lengths[0] ) { (The fix from problem 2 is needed too here.) 3) A third problem with patterns from display hints is that a period (.) is not always escaped with a backslash (\.) (for example with the display hint "1x."). My suggested fix is to use a two-character char array for 'separator', and insert the '\' already when the separator is set from the hint. Then no tests are needed further down, but the %c changed to %s.

2 2

Invalid XML from smidump -f xsd (fractionDigits)
by Arndt Jonasson 31 Jul '06

31 Jul '06

[libsmi 0.4.5, and also most recent.] In dump-xsd.c, there is this line: fprintSegment( f, 0, "<xsd:fractionDigits=\"%d\"/>\n", offset ); As I understand XML, it should be: fprintSegment( f, 0, "<xsd:fractionDigits value=\"%d\"/>\n", offset );

2 1

Malformed patterns using -f xsd
by Arndt Jonasson 31 Jul '06

31 Jul '06

I use libsmi 0.4.5. When I have a textual convention like this one: NiceString ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d1d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2)) it gets translated by the -f xsd option into: <xsd:simpleType name="NiceString"> <xsd:annotation> <xsd:documentation> doc </xsd:documentation> <xsd:appinfo> <displayHint>1d1d</displayHint> <lengths> <length min="2" max="2"/> </lengths> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="((0|[1-9](([0-9]){0,2}))((0|[1-9](([0-9]){0,2})))"/> </xsd:restriction> </xsd:simpleType> Note here that the pattern is malformed: the first opening parenthesis is not closed. The code in getStrDHType which is responsible I find somewhat complicated, but my current fix is to change the line smiAsprintf( &ret, "%s)", ret ); to smiAsprintf( &ret, "%s))", ret ); This is line 585; the header has * @(#) $Id: dump-xsd.c 2609 2005-07-12 07:44:57Z strauss $ This fix may be in the wrong place, though. A second problem I encountered while debugging the above is that this definition: NiceString ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d1d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2 | 2)) causes smidump to hang. In practice this is not a problem - just fix the SIZE specification in the MIB file.

3 2

patch to enhance range unions in smidump generated python & perl
by Randy Couey 13 Jul '06

13 Jul '06

The python & perl smidump modules (and possibly others) don't generate useful code for size/range constraint unions. For example, an object defined with syntax: SYNTAX OCTET STRING (SIZE (1|8)) will result in the following dumped python code: "syntax" : { "type" : { "basetype" : "OctetString", "range" : { "min" : "1", "max" : "1" } "range" : { "min" : "8", "max" : "8" }, }, } This isn't very useful, since the second assignment to the 'range' dictionary key blows away the first one. I have written a patch for the python & perl dumpers to fix this problem. It creates a new key called 'ranges' which references a list of range dictionaries. To ensure backward compatibility, the last 'range' key/value pair is retained. With this patch, the above syntax clause will now get dumped as: "syntax" : { "type" : { "basetype" : "OctetString", "ranges" : [ { "min" : "1", "max" : "1" }, { "min" : "8", "max" : "8" }, ], "range" : { "min" : "8", "max" : "8" }, }, }, This allows knowledgeable apps to iterate through the 'ranges' list and properly deal with constraint unions, while older apps can still use the original, but possibly incorrect, 'range' key. thanks, --randy

2 5

Re: Antwort: Re: [libsmi] patch to enhance range unions in smidump generated python & perl
by Randy Couey 12 Jul '06

12 Jul '06

[...] > I am using the python output format to get MIB module information > (mainly for OID->ObjectName resolution and type information) > for usage based on the PySMNP 3.5.x framework > <http://pysnmp.sourceforge.net>. > I am currently not using the range info. > Therefore, I should have no problem with either change of the range > info. > > PySNMP 4.x has also a script (another one) that uses the > smidump python output format to generate SNMP managed object classes > (and MIB modules). > It will probably have a problem with any change in the range info. > It will be nice to inform the project maintainer of this change. That's actually why I submitted the patch :) I am currently using libsmi2pysnmp from PySNMP 4.x. I have already posted a patch to the pysnmp mailing list that will take advantage of the python smidump changes I've provided to you. I specifically designed both patches so that nothing should break for those users who don't simultaneously upgrade both patches. If you integrate my libsmi patch, I'm sure the pysnmp maintainers will accept by libsmi2pysnmp patch as well. thanks, --randy

1 0