Strange OIDs returned for IBM 3584 v2c trap variables

Discussion in 'Perl Misc' started by John Ramsden, Sep 3, 2003.

  1. John Ramsden

    John Ramsden Guest

    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 ()



    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 : }
     
    John Ramsden, Sep 3, 2003
    #1
    1. Advertisements

  2. In article <>,
    says...

    > 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.

    --
    Michael Kirkham
    Muonics
    http://www.muonics.com/
     
    Michael Kirkham, Sep 4, 2003
    #2
    1. Advertisements

  3. John Ramsden

    John Ramsden Guest

    Michael Kirkham <> wrote in message news:<>...
    >
    > [...]


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

    Cheers

    J Ramsden
     
    John Ramsden, Sep 4, 2003
    #3
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    228
    Steven D'Aprano
    Mar 25, 2007
  2. Robert Wells
    Replies:
    4
    Views:
    798
    Default User
    Jun 24, 2008
  3. SpamMePlease PleasePlease

    Translating pysnmp oids to human readable strings

    SpamMePlease PleasePlease, Mar 5, 2009, in forum: Python
    Replies:
    15
    Views:
    3,634
    Shantanu Joshi
    Mar 9, 2009
  4. Qu0ll
    Replies:
    42
    Views:
    1,488
    Thufir Hawat
    Apr 13, 2009
  5. CISCO OIDs help

    , Oct 13, 2005, in forum: Perl Misc
    Replies:
    7
    Views:
    335
    Josef Moellers
    Oct 13, 2005
Loading...

Share This Page