
Hello, I am using libsmi0.3.1 on Windows NT compiling with VC 6.0. When I load our sample mib module, I get an exception in smiparse() function in the scope of the loadModule() routine.
The code: if ($14) { if (((objectPtr->typePtr->export.basetype == SMI_BASETYPE_OCTETSTRING) && ($14->basetype != SMI_BASETYPE_OCTETSTRING)) || ((objectPtr->typePtr->export.basetype == SMI_BASETYPE_OBJECTIDENTIFIER) && ($14->basetype != SMI_BASETYPE_OBJECTIDENTIFIER))) { smiPrintError(thisParserPtr, ERR_DEFVAL_SYNTAX); if ($14->basetype == SMI_BASETYPE_OBJECTIDENTIFIER) { smiFree($14->value.oid); } if (($14->basetype == SMI_BASETYPE_BITS) || ($14->basetype == SMI_BASETYPE_OCTETSTRING)) { smiFree($14->value.ptr); } smiFree($14); }
gets an exception because objectPtr->typePtr is NULL. I ran smilint.exe against fooTest.mib and it gets an exception also. I have included our sample mibs that I have been testing with. fooTest.mib imports fooCorp.mib.
Any help would be appreciated.
Pamela
-- Pamela Heckmann Icon Laboratories, Inc. Pam_Heckmann@icon-labs.com The grand essentials to happiness in this life are something to do, something to love and something to hope for. - Joseph Addison

Hello, I updated my SMIPATH to point to the ietf mibs. This solved the exception problem. Previously, it pointed to the path for the foocorp and footest modules (not the ietf mib base.)
I am still concerned about the exception.
Thank you.
Pamela
Pamela Heckmann wrote:
Hello, I am using libsmi0.3.1 on Windows NT compiling with VC 6.0. When I load our sample mib module, I get an exception in smiparse() function in the scope of the loadModule() routine.
The code: if ($14) { if (((objectPtr->typePtr->export.basetype == SMI_BASETYPE_OCTETSTRING) && ($14->basetype != SMI_BASETYPE_OCTETSTRING)) || ((objectPtr->typePtr->export.basetype == SMI_BASETYPE_OBJECTIDENTIFIER) && ($14->basetype != SMI_BASETYPE_OBJECTIDENTIFIER))) { smiPrintError(thisParserPtr, ERR_DEFVAL_SYNTAX); if ($14->basetype == SMI_BASETYPE_OBJECTIDENTIFIER) { smiFree($14->value.oid); } if (($14->basetype == SMI_BASETYPE_BITS) || ($14->basetype == SMI_BASETYPE_OCTETSTRING)) { smiFree($14->value.ptr); } smiFree($14); }
gets an exception because objectPtr->typePtr is NULL. I ran smilint.exe against fooTest.mib and it gets an exception also. I have included our sample mibs that I have been testing with. fooTest.mib imports fooCorp.mib.
Any help would be appreciated.
Pamela
-- Pamela Heckmann Icon Laboratories, Inc. Pam_Heckmann@icon-labs.com The grand essentials to happiness in this life are something to do, something to love and something to hope for. - Joseph Addison
Name: fooCorp.mib
fooCorp.mib Type: Notepad File (application/x-unknown-content-type-MIBfile) Encoding: base64
Name: fooTest.mib
fooTest.mib Type: Notepad File (application/x-unknown-content-type-MIBfile) Encoding: base64
-- Pamela Heckmann Icon Laboratories, Inc. Pam_Heckmann@icon-labs.com The grand essentials to happiness in this life are something to do, something to love and something to hope for. - Joseph Addison

Hello,
It appears as if the default value for type object identifier is hardcoded to 0.0. There is a TODO in the file(s) parser-smi*.c.
I need to implement default support for this type and was curious if anybody had done so already.
Thanks for all your help.
Pamela Heckmann Icon Laboratories, Inc.

Pamela Heckmann writes:
Pamela> It appears as if the default value for type object identifier Pamela> is hardcoded to 0.0. There is a TODO in the file(s) Pamela> parser-smi*.c.
Pamela> I need to implement default support for this type and was Pamela> curious if anybody had done so already.
Not sure I really understand what you mean. Can you post a small example of an OBJECT-TYPE with a DEFVAL which does not work?
/js

Here is the object information. It is included in the fooTest.mib I sent out yesterday.
myObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "An object." DEFVAL { { 5 4 3 2 1 } } ::= { fooTest 14 }
I used the function getValueString() from tools dump*.c routines. The valuePtr->len always equals 2 and the oid is set to 0.0.
In the code parse-smi.y, the following code exists: /* TODO: make it work correctly for SMIv1 */ smiPrintError(thisParserPtr, ERR_OID_DEFVAL_TOO_LONG); $$ = smiMalloc(sizeof(SmiValue)); $$->basetype = SMI_BASETYPE_OBJECTIDENTIFIER; $$->len = 2; $$->value.oid = smiMalloc(2 * sizeof(SmiSubid)); $$->value.oid[0] = 0; $$->value.oid[1] = 0;
I hope this helps.
pamela Juergen Schoenwaelder wrote:
Pamela Heckmann writes:
Pamela> It appears as if the default value for type object identifier Pamela> is hardcoded to 0.0. There is a TODO in the file(s) Pamela> parser-smi*.c.
Pamela> I need to implement default support for this type and was Pamela> curious if anybody had done so already.
Not sure I really understand what you mean. Can you post a small example of an OBJECT-TYPE with a DEFVAL which does not work?
/js
-- Juergen Schoenwaelder http://www.informatik.uni-osnabrueck.de/schoenw/
-- Pamela Heckmann Icon Laboratories, Inc. Pam_Heckmann@icon-labs.com The grand essentials to happiness in this life are something to do, something to love and something to hope for. - Joseph Addison

Pamela Heckmann writes:
Pamela> Here is the object information. It is included in the Pamela> fooTest.mib I sent out yesterday.
myObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "An object." DEFVAL { { 5 4 3 2 1 } } ::= { fooTest 14 }
Now I see what you mean. RFC 2578 says in section 7.9:
The value of the DEFVAL clause must, of course, correspond to the SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER, then it must be expressed as a single ASN.1 identifier, and not as a collection of sub-identifiers.
In other words, the correct fix would be to reject the DEFVAL clause altogether and to require that the authors defines an OID value
foo OBJECT IDENTIFIER ::= { 5 4 3 2 1 }
and later uses:
DEFVAL { foo }
Note also that the foo definition is illegal since the first sub-identifier must be 0, 1 or 2 (according to some arcane ASN.1 rules).
Frank, since you are more familiar with the grammar, can you take the token to remove the code that parses nice but illegal OID values in DEFVALs?
/js

Hi!
Juergen> Frank, since you are more familiar with the grammar, can you Juergen> take the token to remove the code that parses nice but Juergen> illegal OID values in DEFVALs?
The parser spits out a warning like...
SOME-SMIv2-MIB:382: warning: OBJECT IDENTIFIER default values must be expressed as a single identifier
I just turned it into an error in case of reading an SMIv2 module:
SOME-SMIv1:191: [4] {default-too-long-smiv1} OBJECT IDENTIFIER default values in form of sub-identifier sequences are not implemented SOME-SMIv2:382: [2] {default-too-long-smiv2} OBJECT IDENTIFIER default values must be expressed as a single identifier
I don't want to eliminate this completely from the grammar, because SMIv1 does not forbid to specify OID DEFVAL as a sequence of sub-identifiers. IMHO, the real TODO here is to full support for SMIv1 (but v1 going to be obsoleted anyway :-)).
-frank

Hi, I am back to this issue. In the libsmi library for v0.3.1 file parser-smi.c, the following code is included: case 184: #line 3374 "parser-smi.y" { /* * SMIv1 allows something like { 0 0 } ! * SMIv2 does not! */ /* TODO: make it work correctly for SMIv1 */ smiPrintError(thisParserPtr, ERR_OID_DEFVAL_TOO_LONG); yyval.valuePtr = smiMalloc(sizeof(SmiValue)); yyval.valuePtr->basetype = SMI_BASETYPE_OBJECTIDENTIFIER; yyval.valuePtr->len = 2; yyval.valuePtr->value.oid = smiMalloc(2 * sizeof(SmiSubid)); yyval.valuePtr->value.oid[0] = 0; yyval.valuePtr->value.oid[1] = 0; ; break;}
I believe this code sets the default oid value to 0.0. If you have a default value in the MIB that is valid for example: myObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "An object." DEFVAL { { 1 3 6 1 4 1 9547 1 1 1 14 0 } } ::= { fooTest 14 }
The default value returned from smidump.exe is: scalar myObjectID { oid fooTest.14; type ObjectIdentifier; access readwrite; default zeroDotZero; description "An object."; };
Are you able use smidump to print out a default for an Object Identifier type other than zeroDotZero?
Thanks, pamela
Pamela Heckmann wrote:
Hello,
It appears as if the default value for type object identifier is hardcoded to 0.0. There is a TODO in the file(s) parser-smi*.c.
I need to implement default support for this type and was curious if anybody had done so already.
Thanks for all your help.
Pamela Heckmann Icon Laboratories, Inc.
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to libsmi-request@ibr.cs.tu-bs.de !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi.
-- Pamela Heckmann Icon Laboratories, Inc. Pam_Heckmann@icon-labs.com Not all those that wander are lost. -J.R.R. Tolkien, novelist and philologist (1892-1973)

Hi!
Pamela> I am back to this issue. In the libsmi library for v0.3.1 file Pamela> parser-smi.c, the following code is included: [...]
Pamela> case 184: Pamela> #line 3374 "parser-smi.y" Pamela> { Pamela> /* Pamela> * SMIv1 allows something like { 0 0 } ! Pamela> * SMIv2 does not! Pamela> */ Pamela> /* TODO: make it work correctly for SMIv1 */ Pamela> smiPrintError(thisParserPtr, Pamela> ERR_OID_DEFVAL_TOO_LONG); Pamela> yyval.valuePtr = smiMalloc(sizeof(SmiValue)); yyval.valuePtr-> basetype = SMI_BASETYPE_OBJECTIDENTIFIER; yyval.valuePtr-> len = 2; yyval.valuePtr-> value.oid = smiMalloc(2 * sizeof(SmiSubid)); yyval.valuePtr-> value.oid[0] = 0; yyval.valuePtr-> value.oid[1] = 0; Pamela> break;}
Pamela> I believe this code sets the default oid value to 0.0. If you Pamela> have a default value in the MIB that is valid for example:
Pamela> myObjectID OBJECT-TYPE Pamela> SYNTAX OBJECT IDENTIFIER Pamela> MAX-ACCESS read-write Pamela> STATUS current Pamela> DESCRIPTION Pamela> "An object." Pamela> DEFVAL { { 1 3 6 1 4 1 9547 1 1 1 14 0 } } Pamela> ::= { fooTest 14 }
This is *NOT* valid. :-) See RFC 2578, Section 7.9.:
If the value is an OBJECT IDENTIFIER, then it must be expressed as a single ASN.1 identifier, and not as a collection of sub-identifiers.
It would be better to accept even illegal OID notation and just spit out an error message, but I did not put too much work on these invalid cases. Please just fix your MIB.
Pamela> The default value returned from smidump.exe is: Pamela> scalar myObjectID { Pamela> oid fooTest.14; Pamela> type ObjectIdentifier; Pamela> access readwrite; Pamela> default zeroDotZero; Pamela> description Pamela> "An object."; Pamela> };
Pamela> Are you able use smidump to print out a default for an Object Pamela> Identifier type other than zeroDotZero?
Yes, if the DEFVAL clause contains an identifier, you will retrieve the corresponding OID.
-frank

Pamela> Hello, I am using libsmi0.3.1 on Windows NT compiling with VC Pamela> 6.0. When I load our sample mib module, I get an exception in Pamela> smiparse() function in the scope of the loadModule() routine.
[...]
Pamela> gets an exception because objectPtr->typePtr is NULL. I ran Pamela> smilint.exe against fooTest.mib and it gets an exception Pamela> also. I have included our sample mibs that I have been testing Pamela> with. fooTest.mib imports fooCorp.mib.
This problem also occurs on Unix - the parser had problems to recover gracefully from missing type definitions. Below is a patch which I just checked into the CVS which seems to fix this problem.
/js
participants (3)
-
Frank Strauss
-
Juergen Schoenwaelder
-
Pamela Heckmann