Overly strict when parsing MIB files

[steveohara]

One of the problems we are getting on an increasingly common basis is Mibble not being able to parse MIB files that all other MIB tools (e.g. iReasoning) can handle without issue. It seems to boil down to the strictness of the parser adhering to the standard - other tools are a lot more accommodating.

Here is a typical example of loading a rack PDU MIB from Austin Hughes;

Warning: in InfraSolutionX-MIB.txt: line 6:
    value identifier 'AustinHughes' doesn't start with a lowercase
    character

    AustinHughes                OBJECT IDENTIFIER ::= { enterprises 34550 } 
    ^
Warning: in InfraSolutionX-MIB.txt: line 7:
    value identifier 'InfraSolutionX' doesn't start with a lowercase
    character

      InfraSolutionX            OBJECT IDENTIFIER ::= { AustinHughes 10 }
      ^
Warning: in InfraSolutionX-MIB.txt: line 8:
    value identifier 'InfraBox' doesn't start with a lowercase
    character

        InfraBox                OBJECT IDENTIFIER ::= { InfraSolutionX 1 }
        ^
Warning: in InfraSolutionX-MIB.txt: line 12:
    value identifier 'FrontHandleControl' doesn't start with a
    lowercase character

        FrontHandleControl              OBJECT IDENTIFIER ::= { handleControl 1 }
        ^
Warning: in InfraSolutionX-MIB.txt: line 13:
    value identifier 'RearHandleControl' doesn't start with a
    lowercase character

        RearHandleControl               OBJECT IDENTIFIER ::= { handleControl 2 }
        ^
Warning: in InfraSolutionX-MIB.txt: line 124:
    value identifier 'InfraBoxAdmin' doesn't start with a lowercase
    character

    InfraBoxAdmin           OBJECT IDENTIFIER ::= { InfraBox 1 }
    ^
Warning: in InfraSolutionX-MIB.txt: line 125:
    value identifier 'InfraBoxModel' doesn't start with a lowercase
    character
[InfraSolutionX-MIB.txt](https://github.com/cederberg/mibble/files/801539/InfraSolutionX-MIB.txt)
etc etc

What are your thoughts? Would it be possible to introduce a flag to indicate non-strict mode?

[cederberg]

The examples listed are all warnings. For the precise purpose of being able to parse the files, while still able to read then properly. Or as Mibble have understood them.

Errors block MIB reading though and I've worked quite a bit to convert most errors to warnings in latest couple of releases...

[steveohara]

Yes they are, but the MIB is still failing to load. The message simply says 'Fail to load xxxxxxxx' The errors are at the bottom of the file;

Error: in InfraSolutionX-MIB.txt: line 1899:
    undefined symbol 'circuitName'

            pduIndex, pduName, pduLocation, circuitIndex, circuitName, circuitState,circuitLoadAmp, circuitLoadAmpAlarmThresh, circuitLoadAmpRisingAlertThresh, circuitLoadAmpLowAlertThresh
Error: in InfraSolutionX-MIB.txt: line 1909:
    undefined symbol 'circuc19OutletIndex'

            pduIndex, pduName, pduLocation, circuc19OutletIndex, c19OutletName, c19OutletAlarmState, c19OutletLoadAmp, c19OutletLoadAmpAlarmThresh, c19OutletLoadAmpRisingAlertThresh, c19OutletLoadAmpLowAlertThresh
                                            ^

This MIB loads fine with iReasoning

[cederberg]

Can you attach the MIB in question to this issue? Or send it via email directly to me? Seems impossible to download it from the Austin Hughes website as far as I can see... 😞

[steveohara]

Apologies, I thought I attached the file in the original ticket. Here it is InfraSolutionX-MIB.mib.txt

[cederberg]

Thanks. I'll add this to the test suite. Unfortunately this MIB file is broken in a few ways that cannot be completely repaired or ignored:

• A number of references (circuitName and circuc19OutletIndex) simply aren't in the MIB (nor imported).
• It uses SYNTAX SEQUENCE OF handleEntry incorrectly (since handleEntry is an OID value, not a type). Should probably have been HandleEntry instead.
• Additionally, lots of symbols uses an incorrect naming standard. Mibble accepts this, but prints lots of warnings, though.

It is clear that no proper MIB validation tool was used for the creation of this MIB. Also clear is that these errors cannot be "auto-repaired" or similar, as Mibble attempts to do for some common issues (missing imports, etc).

I don't know how other tools handle this. Perhaps an option would be to provide an error-to-warning mode that allows leaving types or values set to null? That way one might at least be able to extract other data from the MIB, such as OIDs or symbol names. What do you think? Do you know how iReasoning does this?

As a side-note, I noted that the list of intermingled warnings and errors was rather unreadable for this MIB. Created issue #27 to try to disentangle it a bit.

[steveohara]

You are right about the authors of this MIB, they could not have used a validator. I don't know how iReasoning handles these faults, other than that they don't get announced in any way to the user via their UI. Certainly swapping errors for warnings would be a good idea. We come across this sort of MIB a lot i.e. something created by firmware developers rather than pure software guys. It's probably fair to say that 50% of all MIB files we get from industrial hardware manufacturers cannot be loaded by Mibble, so anything that helps with this would be very good.

[cederberg]

Ok, I see... Will get back to you when I have something to share. Might take a few weeks, though.

[sinaweibo]

i have the same problem, fail to load mib file with mibble while iReasoning mib browser load it successfully

[derekm]

Some vendors publish MIB files with trailing commas...