Strange OIDs returned for IBM 3584 v2c trap variables

[John Ramsden]

I am using the Perl Convert::BER module to decode traps, and it works
fine with both v1 and v2c traps for several MIBs and even caters for
OID indexes.

But in traps received from an IBM 3584, the trap variables' OIDs
end with '.0.0' (except, in v2c traps, the first two standard
variables namely sysUpTime.0 and snmpTrapOID.0) when these
should end with '.1.0'.

When my code replaces the '.0.0' strings by '.1.0' (and then strips
the trailing '.0' as usual) I can locate the variable name from the
'smidump' Perl output for the MIB file ('smidump' being part of the
excellent and indispensable libsmi open-source package for parsing
MIBS - see http://www.ibr.cs.tu-bs.de/projects/libsmi/)

But I'm wondering if this is some peculiarity or bug specific to
the IBM MIB or yet another weird quirk of SNMP itself. Does an OID
with more than one trailing zero have any special significance,
or is there a standard way of dealing with it?

Diagnostic information follows for any would-be SNMP Sherlocks
out there ;-)

(I'd concede this post isn't primarily about Perl. But I've copied
it to comp.lang.perl.misc for possible general interest to anyone
using Perl to deal with SNMP. The bottom line is that with libsmi
and Convert::BER the world, or SNMP world anyway, is your oyster!)


Cheers

John R Ramsden ([email protected])



The following is a cut-down extract from ibm3584v2c.mib:

-- Machine type, model number, library serial number ID
ibm3584MIBGroupMTMNLSN OBJECT IDENTIFIER
::= { ibm3584MIBObjects 11 }

:::

ibm3584MIBObjectsMTMNLSN OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This is the machine type associated with the trap."
::= { ibm3584MIBGroupMTMNLSN 1 }

:::

ibm3584Trap408 NOTIFICATION-TYPE
OBJECTS {
ibm3584MIBObjectsMTMNLSN,
ibm3584MIBObjectsLL,
:::
}

The following is an extract from the 'smidump' Perl output for the
same objects:

{
"name" => "ibm3584MIBGroupMTMNLSN",
"type" => "node",
"module" => "IBM-3584-MIB",
"oid" => "1.3.6.1.4.1.2.6.182.1.2.11",
}, # ibm3584MIBGroupMTMNLSN
{
"name" => "ibm3584MIBObjectsMTMNLSN",
"type" => "scalar",
"module" => "IBM-3584-MIB",
"oid" => "1.3.6.1.4.1.2.6.182.1.2.11.1",
"status" => "current",
"description" =>
'This is the machine type associated with the trap.',
"syntax" => {
"type" =>
{
"basetype" => "OctetString",
"parent" => {
"module" => "SNMPv2-TC",
"name" => "DisplayString",
},
"range" => {
"min" => "1",
"max" => "16"
},
},
},
"access" => "readonly",
}, # ibm3584MIBObjectsMTMNLSN

Finally the following is a Convert::BER dump of the v2c trap
variables in which the rogue [?] OIDs with trailing '.0.0' can
be seen:

0000 A7 284: CONTEXT [7]
{
0004 02 1: INTEGER
= 0
0007 02 1: INTEGER
= 0
000A 02 1: INTEGER
= 0
000D 30 271: SEQUENCE
{
0011 30 16: SEQUENCE
{
0015 06 8: OBJECT ID
= 1.3.6.1.2.1.1.3.0
001F 43 4: APPLICATION [3]

0020 : 03 34 80 66 __ __ __ __ __ __ __ __ __ __ __ __ .4.f
0025 : }
0025 30 28: SEQUENCE
{
0029 06 10: OBJECT ID
= 1.3.6.1.6.3.1.1.4.3.0
0035 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.0.408.0
0045 : }
0045 30 34: SEQUENCE
{
0049 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.11.0.0
0059 04 16: STRING
= '3584 L32 1311031'
006B : }
006B 30 26: SEQUENCE
{
006F 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.21.0.0
007F 04 8: STRING
= '04 55 66'
0089 : }
0089 30 23: SEQUENCE
{
008D 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.31.0.0
009D 04 5: STRING
= '77 88'
00A4 : }
00A4 30 20: SEQUENCE
{
00A8 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.41.0.0
00B8 04 2: STRING
= '02'
00BC : }
00BC 30 22: SEQUENCE
{
00C0 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.51.0.0
00D0 04 4: STRING
= '0000'
00D6 : }
00D6 30 23: SEQUENCE
{
00DA 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.61.0.0
00EA 04 5: STRING
= '09 08'
00F1 : }
00F1 30 43: SEQUENCE
{
00F5 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.71.0.0
0105 04 25: STRING
= 'This is a test SNMP trap.'
0120 : }
0120 : }
0120 : }

 

[Michael Kirkham]

But in traps received from an IBM 3584, the trap variables' OIDs
end with '.0.0' (except, in v2c traps, the first two standard
variables namely sysUpTime.0 and snmpTrapOID.0) when these
should end with '.1.0'.

When my code replaces the '.0.0' strings by '.1.0' (and then strips

I don't see why you'd do that. If you do that in general you're liable
to wind up with something very different from what's actually being
represented by the trap's OIDs.

But I'm wondering if this is some peculiarity or bug specific to
the IBM MIB or yet another weird quirk of SNMP itself. Does an OID
with more than one trailing zero have any special significance,
or is there a standard way of dealing with it?

The .0.0 appears to be a bug in the agent, based on your decoder trace
and the MIB excerpt:

ibm3584MIBObjectsMTMNLSN OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This is the machine type associated with the trap."
::= { ibm3584MIBGroupMTMNLSN 1 } ....
"name" => "ibm3584MIBObjectsMTMNLSN", ....
"oid" => "1.3.6.1.4.1.2.6.182.1.2.11.1", ....
0049 06 14: OBJECT ID
= 1.3.6.1.4.1.2.6.182.1.2.11.0.0
0059 04 16: STRING
= '3584 L32 1311031'

1.3.6.1.4.1.2.6.182.1.2.11.1 <-- OBJECT-TYPE
1.3.6.1.4.1.2.6.182.1.2.11.0.0 <-- trap

Maybe this is why you are being inclined to replace .0.0 by .1.0, but
something else is wrong here. If that actually *is* intended to be
ibm3584MIBObjectsMTMNLSN, then the OID in the trap wrong (or the MIB
definition is wrong). According to the MIB definition it should be:

1.3.6.1.4.1.2.6.182.1.2.11.1.0

Unless what you're actually seeing is some *other* object, defined as..

::= { ibm3584MIBGroupMTMNLSN 0 }

This might be because you're actually seeing some other notification from
the one you quoted from the MIB, since you didn't provide the full
NOTIFICATION-TYPE definition there's no way for me to match up the OID in
the notification to the NOTIFICATION-TYPE.

 

[John Ramsden]

[...]

(replied to in news://comp.protocols.snmp, which is a more appropriate
group in which to continue this discussion (if any))

Cheers

J Ramsden