Libsmi December 2002

libsmi@ibr.cs.tu-bs.de

10 participants
12 discussions

smiquery problems
by Michael Katz 06 Jan '03

06 Jan '03

Hi. I am attempting to use the smiquery tool. I have dowloaded, and fully compiled libsmi-0.4.1. I am using Solaris 2.8 (sparc platform) and the compiler is gcc (version 2.95.2) I have experienced the folowing problems: problem 1: no output for the following command: # smiquery node DS1-MIB_rfc2495.mib::1.3.6.1.2.1.10.18 (DS1-MIB_rfc2495.mib is the standard RFC2495. I have attached it). problem 2: segmentation fault for the following input: # smiquery node HDSL2-SHDSL-LINE-MIB_rfc3276.mib::1.3.6.1.2.1.10.48 (HDSL2-SHDSL-LINE-MIB_rfc3276.mib is the standard RFC3276. I have attached it. I can also send the core if requested.). Perhaps someone can advise. <<mibs.tar.gz>> Thanks in advance, Michael Katz Orckit Communications Ltd. E-mail: michaelkz(a)orckit.com

2 1

walk from iso node - failing....
by Vivekanandan V 30 Dec '02

30 Dec '02

Hi, When Iam giving a walk on iso node, it is failing. I found that the Manager (both Scotty & MGSoft Mib Browser) are sending a request with OID 1.0. Because of this it's failing in the agent side. Questions: ======== 1. Whether we can give a walk from iso ??? 2. If we can do that, then whether the Manager sending the request OID as 1.0 is correct or wrong??? 3. Since there is no node 1.0 registered with our Agent, should we return Failure or fetch the next registered node (1.3) and return to the Manager. Please help me to sort this issue. Thanks & Regards, Vivekanandan.V *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************

2 1

RE: [libsmi] specifying OID value
by Vinoth Palaniappan 26 Dec '02

26 Dec '02

HI David, My intention was to specify an oid value for the mib variable 'test-var9': <oid-value for testObjectIdentity>.1 . For example, if testObjectIdentity's oid-value is x.x.x, where x is a non-negative integer then test-var9's oid-value should be x.x.x.1 . But it seems test-var9 is given an oid-value of 1.1. Am i right? ____________________________________________________________________________ ___________ -Vinoth iDEN OMC Software, Motorola *************************************** *[ ] General Business Information *[X] Motorola Internal Use only *[ ] Motorola Confidential Proprietary *************************************** ____________________________________________________________________________ ___________ >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: Thursday, December 26, 2002 10:56 PM >To: Frank Strauss; Vinoth Palaniappan >Cc: libsmi(a)ibr.cs.tu-bs.de >Subject: Re: [libsmi] specifying OID value > > >HI, > >Frank - it is perfectly legal to specify "{ testObjectIdentity(1) 1 }" >for the OID value. And the result is the OID value of { 1 1 } >Of course, this is probably not the desired result. > >At 02:08 PM 12/26/2002 +0100, Frank Strauss wrote: >>Hi! >> >>Vinoth> I wrote a small mib module and tested with libsmi. I >>Vinoth> encountered a problem and would like to know what i am >>Vinoth> missing. >> >>Vinoth> testObjectIdentity OBJECT-IDENTITY [...] >>Vinoth> ::= { cMIB 1 } >>Vinoth> test-var9 OBJECT-TYPE [...] >>Vinoth> ::= { testObjectIdentity(1) 1 } --LINE NUMBER 51 >> >>Vinoth> I ran the command " smidump -l 5 -f smiv2 E-MIB " and >got error: >>Vinoth> "E-MIB:51: an object named `testObjectIdentity' already exists >>Vinoth> smidump: module `E-MIB' contains errors, expect flawed output" >> >>Vinoth> If i change the line number 51 to ::= { testObjectIdentity 1 } >>Vinoth> , i don't get any error. What is wrong in line number 51? >> >>The OID value of testObjectIdentity is already defined by the >OBJECT-IDENTITY >>construct. The "(1)" in "{ testObjectIdentity(1) 1 }" does >not make sense. >> >>What meaning would you expect? A redundant repitition of the fact that >>the last sub-oid of testObjectIdentity is "1"? Or a redefinition of >>testObjectIdentity to the one-digit OID value "1" and the defintion of >>test-var9 to "1.1"? >> >>Your change to "{ testObjectIdentity 1 }" is (syntactically) >correct and >>defines the value of test-var9 to "testObjectIdentity.1" == >"cMIB.1.1". >> >> -frank > >Regards, >/david t. perkins >

2 1

RE: [libsmi] specifying OID value
by Vinoth Palaniappan 26 Dec '02

26 Dec '02

HI, OK. that might be a silly question for gurus. But still an answer from the SMI guru deserves much more than 25$ and which i can't afford. ____________________________________________________________________________ ___________ -Vinoth iDEN OMC Software, Motorola *************************************** *[X] General Business Information *[ ] Motorola Internal Use only *[ ] Motorola Confidential Proprietary *************************************** ____________________________________________________________________________ ___________ >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: Friday, December 27, 2002 12:27 AM >To: Vinoth Palaniappan >Cc: libsmi(a)ibr.cs.tu-bs.de >Subject: RE: [libsmi] specifying OID value > > >HI, > >When you say > > test-var9 OBJECT-TYPE > ... > ::= { testObjectIdentity(1) 1 } > the OID value is { 1 1 } > >When you say > > test-var9 OBJECT-TYPE > ... > ::= { testObjectIdentity 1 } > the OID value is { <the_oid_value_of_testObjectIdentity> 1 } > >This is "standard ASN.1". > >Please send a donation of US$25 to the LIBSMI Paypal account >to help with expenses at the next meeting. > >At 10:53 PM 12/26/2002 +0530, Vinoth Palaniappan wrote: >>HI David, >> My intention was to specify an oid value for the mib variable >>'test-var9': <oid-value for testObjectIdentity>.1 . For example, if >>testObjectIdentity's oid-value is x.x.x, where x is a >non-negative integer >>then test-var9's oid-value should be x.x.x.1 . But it seems >test-var9 is >>given an oid-value of 1.1. Am i right? >> >>-Vinoth >>iDEN OMC Software, Motorola >> >>>-----Original Message----- >>>From: David T. Perkins [mailto:dperkins@dsperkins.com] >>>Sent: Thursday, December 26, 2002 10:56 PM >>>To: Frank Strauss; Vinoth Palaniappan >>>Cc: libsmi(a)ibr.cs.tu-bs.de >>>Subject: Re: [libsmi] specifying OID value >>> >>> >>>HI, >>> >>>Frank - it is perfectly legal to specify "{ >testObjectIdentity(1) 1 }" >>>for the OID value. And the result is the OID value of { 1 1 } >>>Of course, this is probably not the desired result. >>> >>>At 02:08 PM 12/26/2002 +0100, Frank Strauss wrote: >>>>Hi! >>>> >>>>Vinoth> I wrote a small mib module and tested with libsmi. I >>>>Vinoth> encountered a problem and would like to know what i am >>>>Vinoth> missing. >>>> >>>>Vinoth> testObjectIdentity OBJECT-IDENTITY [...] >>>>Vinoth> ::= { cMIB 1 } >>>>Vinoth> test-var9 OBJECT-TYPE [...] >>>>Vinoth> ::= { testObjectIdentity(1) 1 } --LINE NUMBER 51 >>>> >>>>Vinoth> I ran the command " smidump -l 5 -f smiv2 E-MIB " and >>>got error: >>>>Vinoth> "E-MIB:51: an object named `testObjectIdentity' >already exists >>>>Vinoth> smidump: module `E-MIB' contains errors, expect >flawed output" >>>> >>>>Vinoth> If i change the line number 51 to ::= { >testObjectIdentity 1 } >>>>Vinoth> , i don't get any error. What is wrong in line number 51? >>>> >>>>The OID value of testObjectIdentity is already defined by the >>>OBJECT-IDENTITY >>>>construct. The "(1)" in "{ testObjectIdentity(1) 1 }" does >>>not make sense. >>>> >>>>What meaning would you expect? A redundant repitition of >the fact that >>>>the last sub-oid of testObjectIdentity is "1"? Or a redefinition of >>>>testObjectIdentity to the one-digit OID value "1" and the >defintion of >>>>test-var9 to "1.1"? >>>> >>>>Your change to "{ testObjectIdentity 1 }" is (syntactically) >>>correct and >>>>defines the value of test-var9 to "testObjectIdentity.1" == >>>"cMIB.1.1". >>>> >>>> -frank >>> >>>Regards, >>>/david t. perkins >>> >

1 0

specifying OID value
by Vinoth Palaniappan 26 Dec '02

26 Dec '02

HI, I wrote a small mib module and tested with libsmi. I encountered a problem and would like to know what i am missing. <-------------------START OF MIB---------------------------> C-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI TestString FROM A-MIB; cMIB MODULE-IDENTITY [...] ::= { snmpModules 100 } testObjectIdentity OBJECT-IDENTITY STATUS current DESCRIPTION "abc." REFERENCE "xyz." ::= { cMIB 1 } test-var9 OBJECT-TYPE SYNTAX TestString MAX-ACCESS read-only STATUS current DESCRIPTION "The management context from which to obtain mteTriggerValueID." ::= { testObjectIdentity(1) 1 } --LINE NUMBER 51 END <-------------------END OF MIB---------------------------> I ran the command " smidump -l 5 -f smiv2 E-MIB " and got error: "E-MIB:51: an object named `testObjectIdentity' already exists smidump: module `E-MIB' contains errors, expect flawed output" If i change the line number 51 to ::= { testObjectIdentity 1 } , i don't get any error. What is wrong in line number 51? ____________________________________________________________________________ ___________ -Vinoth iDEN OMC Software, Motorola *************************************** *[ ] General Business Information *[X] Motorola Internal Use only *[ ] Motorola Confidential Proprietary *************************************** ____________________________________________________________________________ ___________

3 2

RE: [libsmi] specifying OID value
by Vinoth Palaniappan 26 Dec '02

26 Dec '02

Oops, I was terribly wrong. Thanks for pointing out. ____________________________________________________________________________ ___________ -Vinoth iDEN OMC Software, Motorola *************************************** *[X] General Business Information *[ ] Motorola Internal Use only *[ ] Motorola Confidential Proprietary *************************************** ____________________________________________________________________________ ___________ >-----Original Message----- >From: Frank Strauss [mailto:strauss@ibr.cs.tu-bs.de] >Sent: Thursday, December 26, 2002 6:38 PM >To: Vinoth Palaniappan >Cc: libsmi(a)ibr.cs.tu-bs.de >Subject: Re: [libsmi] specifying OID value > [...] >The OID value of testObjectIdentity is already defined by the >OBJECT-IDENTITY >construct. The "(1)" in "{ testObjectIdentity(1) 1 }" does not >make sense. > >What meaning would you expect? A redundant repitition of the fact that >the last sub-oid of testObjectIdentity is "1"? Or a redefinition of >testObjectIdentity to the one-digit OID value "1" and the defintion of >test-var9 to "1.1"? > >Your change to "{ testObjectIdentity 1 }" is (syntactically) >correct and >defines the value of test-var9 to "testObjectIdentity.1" == "cMIB.1.1". > > -frank

1 0

smi to xml mappings
by Juergen Schoenwaelder 20 Dec '02

20 Dec '02

There are some discussions going on in various places regarding the original smi -> xml mapping (smidump -f xml) and the current work on smi -> xml schema mappings (smidump -f xsd). I though it would be a good idea to have a common place for these discussions and I have thus created a new mailing list: https://www.ibr.cs.tu-bs.de/mailman/listinfo/smixml Feel free to subscribe if you are interested in this subject. /js -- Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/>

1 0

XML smidump question
by Gerry Buteau 19 Dec '02

19 Dec '02

Using smidump 0.4.2-pre1 it seems like the minLength and maxLength fields disappear at times. I've included two examples... /*------------------------*/ /*------------------------*/ /*------------------------*/ TradiusSecret ::= TEXTUAL-CONVENTION DISPLAY-HINT "32a" STATUS current DESCRIPTION "A secret shared between the RADIUS server and a RADIUS client or another RADIUS server." SYNTAX OCTET STRING (SIZE(1..32)) tradiusSvrAuthClientSecret OBJECT-TYPE SYNTAX TradiusSecret MAX-ACCESS read-create STATUS current DESCRIPTION "The secret shared with the client." ::= { tradiusSvrAuthClientEntry 5 } <xsd:simpleType name="TradiusSecret"> <xsd:annotation> <xsd:documentation> A secret shared between the RADIUS server and a RADIUS client or another RADIUS server. </xsd:documentation> <xsd:appinfo> <displayHint>32a</displayHint> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="(((#x00-#x7f)){1,32})"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="tradiusSvrAuthClientSecret" type="TradiusSecret" minOccurs="0"> <xsd:annotation> <xsd:appinfo> <maxAccess>read-write</maxAccess> <status>current</status> <oid>1.3.6.1.4.1.14707.1.1.7.1.3.1.1.5</oid> </xsd:appinfo> <xsd:documentation> The secret shared with the client. </xsd:documentation> </xsd:annotation> </xsd:element> **Question : Why aren't "minLength" and "maxLength" nodes included? Seems like smidump knows about them, because they are used for the pattern. /*------------------------*/ /*------------------------*/ /*------------------------*/ subscriberImsi OBJECT-TYPE SYNTAX DisplayString (SIZE(13..15)) MAX-ACCESS read-create STATUS current DESCRIPTION "The subscriber's IMSI." ::= { subscriberEntry 4 } <xsd:element name="subscriberImsi" minOccurs="0"> <xsd:annotation> <xsd:appinfo> <maxAccess>read-write</maxAccess> <status>current</status> <oid>1.3.6.1.4.1.14707.1.1.6.1.1.4</oid> </xsd:appinfo> <xsd:documentation> The subscriber's IMSI. </xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="(((#x00-#x7f)){13,15})"/> </xsd:restriction> </xsd:simpleType> </xsd:element> **Also here, no "minLength" or "maxLength"... /*------------------------*/ /*------------------------*/ /*------------------------*/

2 1

xml schema for any MIB file
by Vinoth Palaniappan 19 Dec '02

19 Dec '02

HI, smidump utility has ability to convert SMI files to XML files. I would like to see the XML schema file to which the converted XML file confirms to. I believe this schema file will give how all the constructs(eg. Module Identity, Agent Capabilities etc) defined in SMIv2 should be expressed in a XML document. I looked at http://www.ibr.cs.tu-bs.de/projects/libsmi/xsd/ but didn't find such a verbose schema file. Am i missing something? ____________________________________________________________________________ ___________ -Vinoth iDEN OMC Software, Motorola *************************************** *[X] General Business Information *[ ] Motorola Internal Use only *[ ] Motorola Confidential Proprietary *************************************** ____________________________________________________________________________ ___________

2 1

RE: [libsmi] xsd attribute output
by Steve Bucknam 19 Dec '02

19 Dec '02

Torsten, Thanks for the quick fix. The index attributes now contain the correct enumerations. However, some index attributes now have invalid XML output. I have attached an example MIB along with the XSD output. It appears that the index element "vacmContextName" is printing out twice. The second occurance is nested within the first. In addition, only the root instance of this node has a closing attribute tag. Though, the fix is obviously not to start the second attribute from being added, so it doesn't really matter that it is an unterimated node. I am using today's CVS tree. Steve -----Original Message----- From: Torsten Klie [mailto:tklie@ibr.cs.tu-bs.de] Sent: Friday, December 13, 2002 9:35 AM To: Steve Bucknam Cc: libsmi(a)ibr.cs.tu-bs.de Subject: Re: [libsmi] xsd attribute output Hi Steve! On Fri, Dec 06, 2002 at 09:52:15AM -0500, Steve Bucknam wrote: > I have a table entry with an index that happens to be an enumeration. > An excerpt from the mib follows. When I run smidump on the mib, the > enumerations are lost. The generated type is "Enumeration". I would > have expected there to be a Type of integer with an enumeration of > restrictions just as if the index was any other element in the entry. > I assume this is either a bug or functionality that hasn't been > completed. I would expect to see the restriction information in the > XSD file. Am I wrong? No, you are absolutely right. The code for index attributes was still missing. I have extended the corresponding code and commited it to the CVS. Regards, Torsten

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