[Mibble-users] Re: Mibble 2.2 fails to flag bad syntax of a MIB variable

[Per Cederberg]

On Thu, 2003-11-13 at 22:00, address@hidden wrote:
> Anyways, I have a different question now: how pedantic
> is this MIB parser? In comparison with SMIC and net-snmp parser?
> I find that it fails to detect the following error in the MIB:

In general Mibble should be more pedantic than other 
MIB parsers. I've found minor errors in MIB files that 
seem to have been accepted by other tools. And that 
includes both RFC:s and files from other sources (such 
as a number of files from Cisco... ;-)

That said, there are still issues to be found in Mibble, 
and the library is still evolving. I'm valuate any bug 
or problem reports that come in so that the software 
can improve further.

>     // File: CISCO-AAA-SERVER-MIB.my
>     //...
>     CasConfigEntry ::=
>         SEQUENCE {
>             --casProtocol                  CiscoAAAProtocol,
>             casProtocol                    INTEGER,
>             //...
>         }
> 
>     casProtocol OBJECT-TYPE
>         SYNTAX      CiscoAAAProtocol
>         MAX-ACCESS  not-accessible
>         //...
>        ::= { casConfigEntry 1 }
> 
>     //...
> 
> 
> $  java net.percederberg.mibble.MibbleValidator ./CISCO-AAA-SERVER-MIB.my
> Reading ./CISCO-AAA-SERVER-MIB.my... [OK]
> 
> Files processed:  1
>       with errors:    0
>       with warnings:  0
> $
> 
> Am I missing something or is this another bug? CiscoAAAProtocol is a
> locally defined textual convention with the base syntax of INTEGER.

Actually, version 2.2 was the first one to attempt to 
connect the elements in a SEQUENCE with the "global" 
MIB value symbols. Currently this code only checks for
the existence of the variable, and does not check for
conflicting types or similar. So, that is a known 
validation bug, I guess.

On the other hand, in this case Mibble would probably
only compare the base types. So, the TC INTEGER would
be considered equal to the plain INTEGER, as types are
reduced to their base types as part of the analysis.

You can check out the nasty code where this particular 
validation should live in the SnmpObjectType class, in 
the checkElement() method. I know I had a TODO marker 
there about this, but it seems I made up my mind that 
it wasn't a bug but a feature at some point, so it must
have been removed prior to release. ;-)

Otherwise, you can generally check for "TODO" in the
sources to find a lot of the weak spots. They have not
yet been fully documented, though, and that is one of 
the things currently pending. And now that you reminded
me about these things, I've added bugs #6545 and #6547 
so that they wont be forgotten in the next release.

Many thanks for your comments!

Cheers,

/Per