Ok, the thing is though, we have a few hundred commercial MIBs to import, many of them throw errors. I won't argue the validity of their syntax, but net-snmp has no problem parsing them, and that is what we currently use. Is there some way to configure libsmi to be less strict with its parsing, or skip imports or definitions that have errors?
Jae Muzzin Netmon Technical Support jae@netmon.ca 1-800-944-4511 ext 223
libsmi-request@ibr.cs.tu-bs.de wrote:
Send Libsmi mailing list submissions to libsmi@ibr.cs.tu-bs.de
To subscribe or unsubscribe via the World Wide Web, visit https://mail.ibr.cs.tu-bs.de/mailman/listinfo/libsmi or, via email, send a message with subject or body 'help' to libsmi-request@ibr.cs.tu-bs.de
You can reach the person managing the list at libsmi-owner@ibr.cs.tu-bs.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of Libsmi digest..."
Today's Topics:
- libsmi not parsing MIB (Jae Muzzin)
- Re: libsmi not parsing MIB (Andrew Hood)
Message: 1 Date: Thu, 12 Apr 2007 15:10:12 -0400 From: Jae Muzzin jae@netmon.ca Subject: [libsmi] libsmi not parsing MIB To: libsmi@ibr.cs.tu-bs.de Message-ID: 461E8414.3000402@netmon.ca Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Hello,
I'm using PYSNMP which uses smidump to convert MIBs into python modules. I have a MIB from a manufacturer, which works with net-snmp, but smidump throws a parsing error. Any ideas?
Here is the error: /usr/local/share/mibs/site/enviromux-mini.mib:7: parse error, unexpected DISPLAY_HINT
And here is the part of the mib that is throwing the error:
NETWORK-TECHNOLOGIES-GLOBAL-REG DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, enterprises FROM SNMPv2-SMI DisplayString, TEXTUAL-CONVENTION, DISPLAY-HINT FROM SNMPv2-TC;
On Fri, Apr 13, 2007 at 08:31:51AM -0400, Jae Muzzin wrote:
Ok, the thing is though, we have a few hundred commercial MIBs to import, many of them throw errors. I won't argue the validity of their syntax, but net-snmp has no problem parsing them, and that is what we currently use. Is there some way to configure libsmi to be less strict with its parsing, or skip imports or definitions that have errors?
We are proud there there is no such option.
Besides this, libsmi does actually try to continue as much as possible after errors. If you dislike seeing how bad the input is, redirect the error messages to /dev/zero (and then it is your responsibility that you did so).
/js
Like I said, I'm not arguing how bad the MIB syntax is. But I dont have time to fix hundreds of commercial mibs. This effectively makes libsmi unusable for us. Is there no way at all to have it continue parsing a mib after it finds an error? Jae Muzzin Netmon Technical Support [1]jae@netmon.ca 1-800-944-4511 ext 223
Juergen Schoenwaelder wrote:
On Fri, Apr 13, 2007 at 08:31:51AM -0400, Jae Muzzin wrote:
Ok, the thing is though, we have a few hundred commercial MIBs to import, many of them throw errors. I won't argue the validity of their syntax, but net-snmp has no problem parsing them, and that is what we currently use. Is there some way to configure libsmi to be less strict with its parsing, or skip imports or definitions that have errors?
We are proud there there is no such option.
Besides this, libsmi does actually try to continue as much as possible after errors. If you dislike seeing how bad the input is, redirect the error messages to /dev/zero (and then it is your responsibility that you did so).
/js
References
1. mailto:jae@netmon.ca
Jae Muzzin wrote:
Like I said, I'm not arguing how bad the MIB syntax is. But I dont have time to fix hundreds of commercial mibs. This effectively makes libsmi unusable for us. Is there no way at all to have it continue parsing a mib after it finds an error?
Would you expect a C compiler to produce "any" output if your C program has severe syntax errors, so that it is no valid C program and there is no defined semantics of your "code"?
In other words: no. (Oh, that's just one word.)
On Fri, Apr 13, 2007 at 09:52:39AM -0400, Jae Muzzin wrote:
Like I said, I'm not arguing how bad the MIB syntax is. But I dont have time to fix hundreds of commercial mibs. This effectively makes libsmi unusable for us. Is there no way at all to have it continue parsing a mib after it finds an error?
Like I said, libsmi does continue unless there is a fatal error where it does not know how to continue (in which case someone has to hack the appropriate code to handle the situation or there simply is no way to continue).
In case you talk about smidump, you may want to look at the -k option.
/js
The -k option? I dont see that anywhere on the man page or on the website for smidump. Am I missing something? Thanks for all the help so far. Jae Muzzin Netmon Technical Support [1]jae@netmon.ca 1-800-944-4511 ext 223
Juergen Schoenwaelder wrote:
On Fri, Apr 13, 2007 at 09:52:39AM -0400, Jae Muzzin wrote:
Like I said, I'm not arguing how bad the MIB syntax is. But I dont have time to fix hundreds of commercial mibs. This effectively makes libsmi unusable for us. Is there no way at all to have it continue parsing a mib after it finds an error?
Like I said, libsmi does continue unless there is a fatal error where it does not know how to continue (in which case someone has to hack the appropriate code to handle the situation or there simply is no way to continue).
In case you talk about smidump, you may want to look at the -k option.
/js
References
1. mailto:jae@netmon.ca
On Fri, Apr 13, 2007 at 01:58:34PM -0400, Jae Muzzin wrote:
The -k option? I dont see that anywhere on the man page or on the website for smidump. Am I missing something?
This got added in August last year:
------------------------------------------------------------------------ r5755 | schoenw | 2006-08-16 00:15:42 +0200 (Wed, 16 Aug 2006) | 4 lines
The default behaviour of smidump is now to abort after significant parse errors unless the -k (--keep-going) option has been specified. The tree backend now generates a warning comment if there was a significant parse error.
You may have to upgrade to the subversion version of the tpackage.
/js
participants (3)
-
Frank Strauß -
Jae Muzzin -
Juergen Schoenwaelder