Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
3 of 3

The MIB Compiler is unable to parse certain MIBs

Fixed

Description

I was requested to compile a bunch of MIBs, and the Vaadin UI was complaining about some of them. It was even complaining about dependencies that were already present on the system.

For this reason, I've created a low level JUnit test to figure out what's wrong, and I found a problem on the JsmiMibParser. There was a mistake on the main loop that was never triggered by all the tests that were already there, but I was able to trigger it with the new MIBs I'm trying to compile right now.

That was preventing to finish all the processing, leading to showing dependencies issues for MIBs that were already compiled.

Fortunately, the fix is very easy:

After applying that fix, I was able to parse the new MIBs. All the existing tests are still passing.

 

Acceptance / Success Criteria

None

Attachments

1

Lucidchart Diagrams

Details

Assignee

Reporter

Labels

Components

Fix versions

Affects versions

Priority

PagerDuty

Created March 12, 2019 at 6:23 PM
Updated March 22, 2019 at 1:37 PM
Resolved March 22, 2019 at 1:37 PM

Activity

Show:

Alejandro GalueMarch 14, 2019 at 3:29 PM

Alejandro GalueMarch 14, 2019 at 1:59 PM
Edited

I've verified that the wrong return statement exist on foundation-2016, foundation-2017, foundation-2018 and master, so the fix should be based on foundation-2016.

I'll create a PR with the single code fix, plus a JUnit tests and a bunch of MIBs that are not compiled without the fix. The PR will be based on foundation-2018 due to all the incompatibility issues across foundation branches, so I'll let someone else to back port the fix, if required.

Alejandro GalueMarch 13, 2019 at 6:38 PM

I found the problem with the MIB:

The above is incorrect, as the author of the MIB is trying to use the name inputStateChanged twice, one for an object identifier, and one for a trap definition.

The third-party library we use (i.e. jsmiparser) enters into an infinite look while processing the duplicated definition, leading to the StackOverflowError. This error cannot be caught, leading to the red box we see on the UI.

These kind of bad syntax is not common, but that means we won't be able to show the error on our WebUI, unless we add some defensive code to this third-party library.

In fact, other Java libraries that have a smarter parser like Mibble can confirm what's explained above, as you can see on a custom tool I just made to analyze this problem:

To correct the problem, just rename the trap, or the object to be sure they are unique within the MIB. After that, the MIB can be compiled successfully, even with our UI, after applying the suggested fix.

Alejandro GalueMarch 12, 2019 at 10:38 PM
Edited

There are other issues reflected on the WebUI as shown on the attached screenshot. This looks like a separate problem that happens when compiling BATM-DRY-CONTACTS-MIB. Through a simple JUnit test, I found the problem is a StackOverflowError thrown by the jsmiparser library while parsing this MIB. Of course, this leads to an unexpected exception not handled by the compiler (hence the red box on the UI).

I encountered that error while testing the suggested patch on a VM with M2018. The patch works for the 3 MIBs mentioned before, but not for the one I'm mentioning here.

FYI: the red box appears while compiling BATM-DRY-CONTACTS-MIB with and without the patch.

Alejandro GalueMarch 12, 2019 at 7:01 PM
Edited

The MIBs that I've used to trigger the problem were the following:

  • ADSL2-LINE-MIB

  • VDSL2-LINE-MIB

  • CISCO-SUBSCRIBER-SESSION-MIB