I didn't have enough knowledge of SNMP to tell them with confidence that the
Max wasn't doing the right thing (even though, my intuition told me from the
beginning that the Max was not being consistent).
Now, thanks to your help, I can bang on them until they consider fixing it.
> Marc> The Ascend guy keeps telling me that it's ok for the max to
> Marc> generate 1.3.6.1.4.1.529.1.2.4 along with a trap instead of
> Marc> 1.3.6.1.4.1.529
>
> Please ask him, which RFC defines that this is allowed. Sometimes RFCs
> have contradictions. Please point him to RFC 1215 section 2.1.1.
I sure will. I'm also curious to know what answer he is going to give me (if
any) :-)
> Marc> Is there a way to fix the MIB to cope with the wrong
> Marc> identifier when it is being sent along with a trap? (I can't
> Marc> see how offhand, but just asking)
>
> Well, the obvious fix is to put max4000 into the ENTERPRISE
> clause. This probably means that you have to write a TRAP-TYPE macro
> for every ascend device type.
Correct, but then I only monitor this device, those I'll be fine.
However, I did try to make that change already, and I have the following
problem:
--- ascendtrp.mib.sav Wed May 28 07:49:51 1997
+++ ascendtrp.mib Wed May 28 08:47:20 1997
@@ -22,7 +22,7 @@
IMPORTS
ifIndex, sysName
FROM RFC1213-MIB
- ascend
+ max4000
FROM ASCEND-MIB
consoleIndex
FROM ASCEND-MIB
@@ -70,14 +70,14 @@
-- state which is often a direct result of a call state change.
portInactive TRAP-TYPE
- ENTERPRISE ascend
+ ENTERPRISE max4000
VARIABLES { ifIndex }
DESCRIPTION "The host port associated with the indicated ifIndex
has changed to the inactive state."
::= 0
(...)
% mib load ascendtrp.mib
ascendtrp.mib: no parent max4000 for node max4000Traps
ascendtrp.mib: no parent max4000 for node max4000Traps
ascendtrp.mib: no parent max4000 for node max4000Traps
(...)
ascendtrp.mib: no parent max4000Traps for node portInactive
ascendtrp.mib: no parent max4000Traps for node portDualDelay
ascendtrp.mib: no parent max4000Traps for node portWaitSerial
(...)
I'm not sure why it doesn't see max4000, since I import it from the main
ascend file.
Anyway, I ended up concatenating the ascend.mib file with the ascendtrp.mib
file, and the parser is now happy (not very clean, but it works).
And now, tada...,
Wed May 28 09:21:06 PDT 1997 SNMPv1 trap from [198.147.96.77]:
sysUpTime.0 = 73d 7:26:33.00
snmpTrapOID.0 = ASCEND-TRAP!consoleStateChange
consoleIndex.2 = 2
snmpTrapEnterprise.0 = max4000
Thank you very much for your help, I wouldn't have gotten it to work without
you.
(If you have a pointer to the RFC I should read to be able to understand and
fix simple MIB mistakes like that, I'll happily read it).
> Sure, I could hack some code to deal with this particular case.
> However, there are so many ugly SNMP implementations out there that it
> is very difficult to work around all the bugs. I therefore decided a
> while back that it is best to follow the standards as closely as
> possible and to let people point out the problems so that the bugs get
> fixed. It also helps to understand where the SNMP specs are bogus.
I understand, and it is a wise choice. I also wish that vendors would be
more careful and admit it when they make mistakes, and fix them. Yet, it is
not always an option.
As you mentionned, an ugly MIB hack fixes the problem here, so no reason to
mess with source code. Hopefully, I'll get Ascend to fix their code, but
even if I do, my boss is too paranoiac for letting me upgrade the software
in a "perfectly working router", so your suggestions for a "home fix" were
invaluable.
Best,
Marc
-- !! 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.