Some clarifications about smilib errors reporting
Hello,
While working with various mib files and their processing with smilib, I came across following points which I felt that I should mention.
(# 1)
I have two files : 1) A-MIB 2) B-MIB
A-MIB contains 5 modules: 1) A-MIB 2) A1-MIB 3) A2-MIB 4) A3-MIB 5) A4-MIB
B-MIB contains one module: 1) B-MIB
B-MIB imports two identifiers id1 and id2 from module A-MIB(i.e first module in the file), which are defined in that module.
while loading these two modules (using smiLoadModule()) A-MIB and B-MIB in the following order : First -> B-MIB Second -> A-MIB
(These two files are present in the working directory, i.e where libsmi searches for the presence of the modules)
While loading the first file (B-MIB) , I get following error messages from the compiler :
identifier `id1' cannot be imported from module `A4-MIB' identifier `id2' cannot be imported from module `A4-MIB' ...
I think that while loading the module B-MIB from the file B-MIB, libsmi loads the A-MIB from which B-MIB imports some identifiers. And the access pointer (or module pointer whatever ) in the file A-MIB has reached the last module (A4-MIB). Instead of searching the identifiers in the first module in that file, they are searched in the last module (where they are not present) of that file.
(#2)
Whenever following error message is obtained while compiling a faulty module by smilib :(File 'TEST'containing module XXX)
"C:\TestDir\SNMP\XXX: unable to determine SMI version"
I observed that, the file from which A-MIB is being read is locked or some handle to that file which was obtained by smilib is not released ( Even after releasing the smilib resources i.e doing smiExit()). Unless the calling application is closed, the file remains locked by some process and can not be deleted. Can this be the case ? Any solution ?
At the same time whenever this error is obtained, the 'path' name is indicated by 'NULL'. I felt that it would be more helpful if the full path is reported in the 'path' variable. (Althoug it is properly reported in the 'message' parameter of the errorhandler function). Some other errors also report 'path' as null for severe errors found in the module being processed.For example : "failed to locate MIB module `SNA-NAU-MIB'".
Is it possible to get the complete file/module name 'path'(in the path parameter) for such errors?
(#3)
Few mib files contain following kind of syntax:
"
IBM-8271-EtherStreamer-Switch-MIB {iso org(3) dod(6) internet(1) private(4) enterprises(1) 2} DEFINITIONS ::= BEGIN
-- IBM 8271 EtherStreamer Switch MIB Release 1.1 ...
"
smilib does not accept this. A parse error is obtained. The {....} construct appearing before DEFINITIONS clause seems to be causing the problem. Should the mib files be changed or this is a valid construct ?
Thanks, Abhay
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi!
Abhay> While working with various mib files and their processing with smilib, I Abhay> came across following points which I felt that I should mention.
Thanks a lot for your feedback!
Abhay> (# 1)
Abhay> I have two files : 1) A-MIB 2) B-MIB
Abhay> A-MIB contains 5 modules: Abhay> 1) A-MIB Abhay> 2) A1-MIB Abhay> 3) A2-MIB Abhay> 4) A3-MIB Abhay> 5) A4-MIB
Abhay> B-MIB contains one module: Abhay> 1) B-MIB
Abhay> B-MIB imports two identifiers id1 and id2 from module A-MIB(i.e Abhay> first module in the file), which are defined in that module.
Abhay> while loading these two modules (using smiLoadModule()) A-MIB Abhay> and B-MIB in the following order : Abhay> First -> B-MIB Abhay> Second -> A-MIB
Abhay> (These two files are present in the working directory, i.e Abhay> where libsmi searches for the presence of the modules)
Abhay> While loading the first file (B-MIB) , I get following error Abhay> messages from the compiler :
Abhay> identifier `id1' cannot be imported from module `A4-MIB' Abhay> identifier `id2' cannot be imported from module `A4-MIB' Abhay> ...
Abhay> I think that while loading the module B-MIB from the file Abhay> B-MIB, libsmi loads the A-MIB from which B-MIB imports some Abhay> identifiers. And the access pointer (or module pointer whatever Abhay> ) in the file A-MIB has reached the last module (A4-MIB). Abhay> Instead of searching the identifiers in the first module in Abhay> that file, they are searched in the last module (where they are Abhay> not present) of that file.
I have to admit that the multiple-modules-per-file feature is not well tested. I'll look at this problem later on. Maybe, you could use the one-module-per-file-named-by-the-module scheme for now.
Abhay> (#2)
Abhay> Whenever following error message is obtained while compiling a Abhay> faulty module by smilib :(File 'TEST'containing module XXX)
Abhay> "C:\TestDir\SNMP\XXX: unable to determine SMI version"
Abhay> I observed that, the file from which A-MIB is being read is Abhay> locked or some handle to that file which was obtained by smilib Abhay> is not released ( Even after releasing the smilib resources i.e Abhay> doing smiExit()). Unless the calling application is closed, the Abhay> file remains locked by some process and can not be deleted. Abhay> Can this be the case ? Any solution ?
There have been some fclose() calls missing. It's fixed now in the CVS repository. Thanks!
Abhay> At the same time whenever this error is obtained, the 'path' Abhay> name is indicated by 'NULL'. I felt that it would be more Abhay> helpful if the full path is reported in the 'path' variable. Abhay> (Althoug it is properly reported in the 'message' parameter of Abhay> the errorhandler function). Some other errors also report Abhay> 'path' as null for severe errors found in the module being Abhay> processed.For example : "failed to locate MIB module Abhay> `SNA-NAU-MIB'".
Abhay> Is it possible to get the complete file/module name 'path'(in Abhay> the path parameter) for such errors?
In the failed-to-locate case it's obviously not possible. ;-) But I changed the unable-to-determine-version case (without testing the change yet).
Abhay> (#3)
Abhay> Few mib files contain following kind of syntax:
Abhay> "
Abhay> IBM-8271-EtherStreamer-Switch-MIB {iso org(3) dod(6) internet(1) private(4) Abhay> enterprises(1) 2} Abhay> DEFINITIONS ::= BEGIN
Abhay> -- IBM 8271 EtherStreamer Switch MIB Release 1.1 Abhay> ...
Abhay> "
Abhay> smilib does not accept this. A parse error is obtained. The Abhay> {....} construct appearing before DEFINITIONS clause seems to Abhay> be causing the problem. Should the mib files be changed or this Abhay> is a valid construct ?
This is legal. It should be accepted by the parser, though ignored. It should just give a notice: ./IBM-8271-EtherStreamer-Switch-MIB:2: implicit node definition
Could you send me the MIB file or another example which would let me reproduce the parse error?
-frank -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
participants (2)
-
Deshmukh, Abhay -
Frank Strauss