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

failed to locate MIB module ...
by 최대영 26 Apr '02

26 Apr '02

Hi, all. This is the first time for me to use libsmi mailinglist. I'm elementary in using this tool. I installed libsmi as documentation. When I try to test some commands, some problems occurred. I think these problems occurred because of missing mib path. I want to know how to locate mib modules path. Should I modify smi.conf ? Or, simply should I set environment variable 'mibdir' ? $ smidump ./IF-MIB failed to locate MIB module `SNMPv2-SMI' failed to locate MIB module `SNMPv2-TC' failed to locate MIB module `SNMPv2-CONF' failed to locate MIB module `SNMPv2-MIB' failed to locate MIB module `IANAifType-MIB' ./IF-MIB:81: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:95: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:110: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:111: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:118: unknown type `TimeTicks' ./IF-MIB:119: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:120: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:140: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:141: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:149: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:150: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:163: unknown type `Gauge32' ./IF-MIB:167: unknown type `TimeTicks' ./IF-MIB:168: unknown type `Counter32' ./IF-MIB:169: unknown type `Counter32' ./IF-MIB:170: unknown type `Counter32' ./IF-MIB:171: unknown type `Counter32' ./IF-MIB:172: unknown type `Counter32' ./IF-MIB:173: unknown type `Counter32' ./IF-MIB:174: unknown type `Counter32' ./IF-MIB:175: unknown type `Counter32' ./IF-MIB:176: unknown type `Counter32' ./IF-MIB:177: unknown type `Counter32' ./IF-MIB:178: unknown type `Counter32' ./IF-MIB:179: unknown type `Gauge32' ./IF-MIB:187: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:188: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:199: illegal size restriction for non-octet-string parent type `Display String' ./IF-MIB:200: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:201: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:207: type of `ifDescr' in sequence and object type definition do not ma tch ./IF-MIB:211: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:212: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:222: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:223: invalid STATUS `current' in SMIv1 MIB ./IF-MIB:236: unknown type `Gauge32' ./IF-MIB:236: MAX-ACCESS is SMIv2 style, use ACCESS in SMIv1 MIBs instead ./IF-MIB:237: invalid STATUS `current' in SMIv1 MIB 0 [main] smidump 1012 handle_exceptions: Exception: STATUS_ACCESS_VIOLATIO N 36374 [main] smidump 1012 stackdump: Dumping stack trace to smidump.exe.stackd ump Segmentation fault (core dumped)

1 0

Re: [libsmi] Error report when there is a failure to import a file
by Bill Fenner 22 Apr '02

22 Apr '02

I did this in parser-smi.y to get the line numbers: --- parser-smi.y 20 Mar 2002 16:49:49 -0000 1.169 +++ parser-smi.y 21 Apr 2002 17:38:11 -0000 @@ -1339,6 +1340,10 @@ modulePtr = findModuleByName($3); if (!modulePtr) { modulePtr = loadModule($3); + /*XXX duplicate error, but with line # */ + if (!modulePtr) + smiPrintError(parserPtr, + ERR_MODULE_NOT_FOUND, $3); } checkImports(modulePtr, thisParserPtr); It doesn't suppress the error that loadModule prints, so you get two copies of the MODULE_NOT_FOUND error, but it at least gives you the info. [This patch will not apply directly due to whitespace corruption - just add the 3 or 4 lines by hand] Bill

3 2

RE: [libsmi] Errors while accessing it in DLL
by Hills, Steve 16 Apr '02

16 Apr '02

Are you including the header file in a C++ file? If so then do extern "C" { #include "smi.h" } This will force the included header file to keep the C export names (and not do C++ name mangling). Also, I'm assuming your building this on Windows (Win32)? I am also and the libsmi code crashes on the call to smiExit(). If you run into this and find the fix please forward it to me. Steve Hills -----Original Message----- From: Save, Amit Prabhakar (Amit) [mailto:save@agere.com] Sent: Tuesday, April 16, 2002 4:39 AM To: Salam, Abdul Cc: libsmi(a)ibr.cs.tu-bs.de Subject: RE: [libsmi] Errors while accessing it in DLL Hi, I have cerated a lib from LibSmi say smiDump.lib. I'm making a call to smiDumpMain() inside this smiDump.lib from my code. Now I'm creating a DLL of my code. Similalrly, when I used to create an EXE of my code, I never faced this problem. Here too I was making a call to smiDumpMain() inside this smiDump.lib Thanks & regards, Amit Save -----Original Message----- From: Salam, Abdul [mailto:Abdul.Salam@barconet.com] Sent: Tuesday, April 16, 2002 5:02 PM To: 'Save, Amit Prabhakar (Amit)' Subject: RE: [libsmi] Errors while accessing it in DLL Of course You are linking the wrong dll. -----Original Message----- From: Save, Amit Prabhakar (Amit) [mailto:save@agere.com] Sent: Tuesday, April 16, 2002 4:52 PM To: libsmi(a)ibr.cs.tu-bs.de Subject: [libsmi] Errors while accessing it in DLL Hi, I have created one lib instead of creating smidump.exe. The main fn. in smidump.c was renamed to smiDumpMain(). So that I could access it inside my code as a Library rather than to run it as a command. I hope till this everything is fine? When I try to use it in my code, at the time of linking I get errors as Mibcompiler.obj : error LNK2001: unresolved external symbol __imp__smiDumpMain When I was building an EXE of my code making a call to smiDumpMain(), everything used to work fine. I have ran the code also & it works fine. But if I build a DLL of my code making a call to smiDumpMain(), the above error comes up. Regards, Amit Save -- !! 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(a)ibr.cs.tu-bs.de> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi. -- !! 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(a)ibr.cs.tu-bs.de> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi.

1 0

RE: [libsmi] Errors while accessing it in DLL
by Save, Amit Prabhakar (Amit) 16 Apr '02

16 Apr '02

Hi, I have cerated a lib from LibSmi say smiDump.lib. I'm making a call to smiDumpMain() inside this smiDump.lib from my code. Now I'm creating a DLL of my code. Similalrly, when I used to create an EXE of my code, I never faced this problem. Here too I was making a call to smiDumpMain() inside this smiDump.lib Thanks & regards, Amit Save -----Original Message----- From: Salam, Abdul [mailto:Abdul.Salam@barconet.com] Sent: Tuesday, April 16, 2002 5:02 PM To: 'Save, Amit Prabhakar (Amit)' Subject: RE: [libsmi] Errors while accessing it in DLL Of course You are linking the wrong dll. -----Original Message----- From: Save, Amit Prabhakar (Amit) [mailto:save@agere.com] Sent: Tuesday, April 16, 2002 4:52 PM To: libsmi(a)ibr.cs.tu-bs.de Subject: [libsmi] Errors while accessing it in DLL Hi, I have created one lib instead of creating smidump.exe. The main fn. in smidump.c was renamed to smiDumpMain(). So that I could access it inside my code as a Library rather than to run it as a command. I hope till this everything is fine? When I try to use it in my code, at the time of linking I get errors as Mibcompiler.obj : error LNK2001: unresolved external symbol __imp__smiDumpMain When I was building an EXE of my code making a call to smiDumpMain(), everything used to work fine. I have ran the code also & it works fine. But if I build a DLL of my code making a call to smiDumpMain(), the above error comes up. Regards, Amit Save -- !! 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(a)ibr.cs.tu-bs.de> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi.

1 0

Errors while accessing it in DLL
by Save, Amit Prabhakar (Amit) 16 Apr '02

16 Apr '02

Hi, I have created one lib instead of creating smidump.exe. The main fn. in smidump.c was renamed to smiDumpMain(). So that I could access it inside my code as a Library rather than to run it as a command. I hope till this everything is fine? When I try to use it in my code, at the time of linking I get errors as Mibcompiler.obj : error LNK2001: unresolved external symbol __imp__smiDumpMain When I was building an EXE of my code making a call to smiDumpMain(), everything used to work fine. I have ran the code also & it works fine. But if I build a DLL of my code making a call to smiDumpMain(), the above error comes up. Regards, Amit Save

1 0

Warning given is correct??
by Vivekanandan V 08 Apr '02

08 Apr '02

Hello, I have defined the SYNTAX of one mib objects as "InetAddressIPv4" - Imported from INET-ADDRESS-MIB. The smilint tool gives an warning that "'InetAddress' should be used instead of `InetAddressIPv4". What is the meaning of this warning?? Is this warning correct?? 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

problem in tool when checking the access of Index elements
by Vivekanandan V 05 Apr '02

05 Apr '02

Hello, Iam having an Index element which is also an OBJECT for an NOTIFICATION-TYPE object. And Iam having the MAX-ACCESS of this Index element as "accessible-for-notify". The smilint tool gives an warning that "Index element should be not-accessible", which is wrong for this case. So an extra check should be put for this also. 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. ***************************************************************************

3 4

Re: [libsmi] problem in tool when checking the access of Index elements
by Frank Strauss 05 Apr '02

05 Apr '02

Hi! Vivekanandan> Iam having an Index element which is also an OBJECT for Vivekanandan> an NOTIFICATION-TYPE object. And Iam having the Vivekanandan> MAX-ACCESS of this Index element as Vivekanandan> "accessible-for-notify". The smilint tool gives an Vivekanandan> warning that "Index element should be not-accessible", Vivekanandan> which is wrong for this case. So an extra check should Vivekanandan> be put for this also. An interesting situation! :-) However, RFC 2578, Section 7.7 doesn't allow another MAX-ACCESS value than not-accessible in this case. Your MIB should not use the not-accessible index object in the notification type's OBJECTS clause, but another column of the conceptual table. And in most cases this even makes sense :-): Notifications are raised on specific conditions. You usually want to carry not only the instance information but also some information about this condition, e.g. the current status on a status change notification or a current rate on a threshold notification. -frank

1 0

Suggestion....
by Vivekanandan V 05 Apr '02

05 Apr '02

Hi, It will be very useful for us, if the new Release details, bug-fixes made,.... in the smilint tool can be announced in this mailing list itself. 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. ***************************************************************************

1 0

Clarification req......
by Vivekanandan V 03 Apr '02

03 Apr '02

Hello, In Isis mib (draft-ietf-isis-wg-mib-05.txt), the objects of a table are not assigned continuous OID's. Please let me know, whether this is correct or whether continuous OID's must only be assigned to Table elements. 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