Relaxed mode for parsing invalid MIBs #37
Comments
|
This isn't really practical with the current parser. I also don't know how many people might be using the library for linting, so I would want to be very careful about introducing any such workarounds without also including flags to be able to control them. I have cloned the LibreNMS MIBs myself and have used them for some testing. CISCOSB-SYSMNG-MIB, for example, looks like it was correct until a bulk update ~10 months ago that messed up the revision dates. Unfortunately, it doesn't look like there have been checks added to their CI process to do linting or any other validation on the included MIB files, so they do get committed with errors, sometimes even regressions it seems. I'm always happy to address bugs in the library for spec-compliant MIB files, but I would suggest in this scenario to open an issue against the LibreNMS repo to work on getting things corrected there. |
I'll rename the issue to reflect a bit better the goal of the issue.
All (guessing 99%) comes directly, unmodified, from the vendor, this is more a reflection of the [sad] state of mibs out in the wild.
I'm on of the maintainers there, and I don't think we (LibreNMS) can/should modify vendor mibs |
Jellyfrog
changed the title
The new title I agree with. I've started to work on a major rewrite of the library's core that should start to help with some common errors in MIBs (like textual convention inheritance), but unfortunately I can't address parsing-related issues until I can replace the existing parser. As stated previously, I want to make sure that there is still a way to use the library as a linter, so I don't want to introduce any changes without still providing an option for spec compliance. The immediate goal it to reach parity with the original libsmi C library in what it is able to load (despite some errors), but my ultimate goal is to be able to load any MIB that Net-SNMP can. Unfortunately, my time is limited, so I can't commit to a timeline on this. A lot of work has already been completed, but not much on the parser yet.
Yeah, the ones out in the wild are often pretty bad. Some vendors are certainly worse than others. I'm mostly happy when I can even get MIBs for a product, but too often even the latest available seem to be outdated when actually trying to walk a device.
I don't necessarily agree with that statement. If there's a change that can be made to correct a syntax issue and it allows for the MIB file to be more fully parsed or otherwise create more useful information, then I think it would be in everyone's best interest to do so. In my career, I've definitely done that for some vendor MIBs, even going so far as correcting types, enum values, adding missing objects, and so on, so that I can actually consume the MIB and do something useful with it. You definitely have to stay vigilant though, because I have had vendors fix some of those kind of bugs in newer firmware releases. That's why it's always important to try to use not just the correct MIBs, but the correct revisions for a particular device and firmware version. MIBs are supposed to be backwards compatible, but that's another thing that vendors all too often mess up as well. Depending on your relationship with the vendor, you can try opening a ticket with them to "properly" correct the issue, but I have not had great success with most vendors going that route (even ones with active support contracts). Especially for older/unsupported products or companies that no longer exist, there's really little recourse to get the problem fixed at the source. |
Librenms got a decent collection of MIBs from various vendors, some more broken than others.
It might be of interest to add a "relaxed mode" for common problems, such as the ones with invalid dates:
unexpected "201506080000A" (expected <extutctime> ...)The text was updated successfully, but these errors were encountered: