On Wed, 5 Apr 2000, George Ross wrote:
> > Having spent many a jolly hour fiddling with HP MIBs and
> > corresponding with folks at HP to find what order to load them in (and
> > still not getting them all loaded), may I pick your brains and ask which
> > MIBs you load, in which order? (And where you get them from & what's your
> > favourite vintage?!)
>
> The set I've used is off the CDROM that came in the box with the 4000.
> The readme.htm file on it is dated September 8th 1999.
but the mibs themselves are a year older - 24/09/98 (mostly)
> The only two mibs I've used in anger off it are config.mib and
> hpvlan.mib, which don't seem to depend on anything else.
>
> In my quick-and-dirty tree-walker I used a hack to load them in two
> batches, *.mib and *.xxx, just in alphanumeric order within each batch. I
> started out with them all called .mib, repeatedly ran the program, and each
> time one failed to parse I renamed it from .mib to .xxx. Eventually the
> following all loaded, in this order:
>
> config.mib hphttpmg.mib hpstack.mib icfsecur.mib netswtst.mib
> dma.mib hpicfoid.mib hpvgrptr.mib icfvg.mib stat.mib
> drivers.mib hpltst.mib hpvlan.mib iftype.mib vg.mib
> hpentmib.mib hprptr.mib icfetwst.mib ipx.mib
>
> hpbasic.xxx hpchasis.xxx hpff.xxx
> hpchain.xxx hpdwnld.xxx hpgnrptr.xxx
You mean you also got the .xxx ones to load?
I have tried (from scotty % prompt, using 2.1.10)
mib load config.mib
mib load dma.mib
mib load drivers.mib
mib load hpentmib.mib
mib load hphttpmg.mib
mib load hpicfoid.mib
mib load hpltst.mib
mib load hprptr.mib
mib load hpstack.mib
mib load hpvgrptr.mib
mib load hpvlan.mib
mib load icfetwst.mib
mib load icfsecur.mib
mib load icfvg.mib
mib load iftype.mib
mib load ipx.mib
mib load netswtst.mib
mib load stat.mib
mib load vg.mib
all OK so far, and from your .xxx bunch I can load:
mib load hpbasic.mib
mib load hpff.mib
mib load hpgnrptr.mib
but when I try:
% mib load hpchain.mib
scotty complains:
unable to parse ENTERPRISE {
hpchain.mib:236: bad format in TRAP-TYPE
couldn't parse MIB file "hpchain.mib"
at line 236 of the mib there is:
hpicfChainAddition TRAP-TYPE^M
ENTERPRISE { hpicfCommonTraps }^M
VARIABLES { hpicfChainId }^M
DESCRIPTION^M
"********* THIS NOTIFICATION IS DEPRECATED *********^M
^M
An hpicfChainAddition trap indicates that a new node^M
has been added to the Distributed Management Chain^M
connected to this agent. The hpicfChainId returned^M
is the identifier for the new node.^M
^M
Replaced by Cold Start"^M
::= 1^M
^M
However the hpbasic mib (which loads OK) has something similar:
hpicfSelfTestTrap TRAP-TYPE^M
ENTERPRISE { hpicfCommonTraps }^M
VARIABLES { hpicfSelfTestResultText }^M
DESCRIPTION^M
"An hpicfSelfTestTrap indicates that the agent has^M
---8<--- snip ---8<---
recipients.)."^M
::= 4^M
^M
In the past I have had a problem with scotty failing to parse a mib where
there wasn't whitespace somewhere around the ::= - in that case scotty
complained:
test.mib:37: Warning: cannot scan enums - ignored
test.mib:37: bad mib format
test.mib:37: bad mib format
on a line like
fooBar OBJECT IDENTIFIER::={generic 33}
whereas
fooBar OBJECT IDENTIFIER ::= {generic 33}
made it all OK ^ ^
(That was with Scotty 2.1.9)
I can't see anything similar here though.
Any ideas anyone?
> That seems to work for me. I haven't bothered with the rfc ones yet.
Sotty already has most loaded. The additional ones seem to be:
rfc2239.mib
rfc2233.mib
rfc2358.mib
and rfc2037.mib - but I get errors trying to load this.
--
John Stumbles j.d.stumbles@reading.ac.uk
I.T. Services Centre, University of Reading http://www.rdg.ac.uk/~visstmbl
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Press any key to continue or any other key to quit.
--
!! 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.
This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 15:27:40 MET