Re: [tkined] MIB loading question(s) for Scotty

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Tue, 11 Nov 1997 17:19:00 +0100

"Jeff Choate" <jchoate@fore.com> said:

Jeff> I am running on Solaris with Scotty2.1.7. I am trying to load
Jeff> the ATM-TC-MIB into Scotty, and I am having a couple of
Jeff> problems that I hope this group may be able to help me out
Jeff> with.

Jeff> My first question concerns deprecated OBJECT-GROUP and
Jeff> OBJECT-IDENTITY objects. Deprecated OBJECT-TYPE objects are
Jeff> read and parsed correctly, but when a deprecated OBJECT-GROUP
Jeff> or OBJECT-IDENTITY object is read, Scotty gives back the error
Jeff> message: 105 --> deprecated atm2TC05.mib:169 bad format in
Jeff> OBJECT-GROUP

Jeff> Is this because of an SNMP rule that OBJECT-GROUP objects may
Jeff> not be deprecated or something like that?

No, it is a bug in the MIB parser. It is already fixed in my source
tree, but I don't have a patch handy for the 2.1.7 parser. Change the
status to current in order to work around the bug.

Jeff> My next question concerns reading in the indexes in MIB definitions.
Jeff> In the ATM-TC-MIB, the mib identity is specified as:

Jeff> atmTCMIB MODULE-IDENTITY
Jeff> LAST-UPDATED "9610220200Z"
Jeff> ORGANIZATION "IETF AToMMIB Working Group"
Jeff> CONTACT-INFO " Michael Noto"
Jeff> ::=3D { mib-2 37 3 }

Jeff> also, within the mib, an object identity is created as follows:
Jeff> atmTrafficDescriptorTypes OBJECT IDENTIFIER ::=3D {mib-2 37 1 1}

This is another known bug in the MIB parser. The parser can't handle a
definition like { mib-2 37 3 }. You can work around the problem by
changing it to { mib-2 atmMIB(37) 3 }. Make sure you load the MIB
module which defines atmMIB before loading ATM-TC-MIB.

Jeff> I am theorizing that Scotty is only reading in the parent and
Jeff> then a single index for the node, in this case for the MIB
Jeff> identifier. When it parses the next object with a compound
Jeff> identity, it is already allocated to another object and so is
Jeff> skipped.

Quite good, though not 100 % correct. The internals of the MIB parser
use the MIB node names to build the internal MIB tree. Every node
definition without a name causes problems. Adding a label as shown
above solves this problem. I don't have a simple fix for this.

Juergen

-- 
Juergen Schoenwaelder  schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, D-38106 Braunschweig, Germany.     (Tel. +49 531 / 391-3283)
--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.