[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mibble-users] Re: Mibble 2.2 fails to flag bad syntax of a MIB variable
From: |
Per Cederberg |
Subject: |
[Mibble-users] Re: Mibble 2.2 fails to flag bad syntax of a MIB variable |
Date: |
Fri, 14 Nov 2003 01:30:39 +0100 |
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