SNMP trap config

[gormank]

Just one, that may not have an answer...
In ThreeParMIB.mib I see this, which corresponds to 232 for HP.
::= { enterprises 12925 }

But when I snmpwalk, I get nothing.

# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 1.3.6.1.4.1.12925
ThreeParMIB::threepar = No Such Object available on this agent at this OID

# snmpwalk -t 300 -v 2c -Cc -On -c sp1der txslm2mfchp001 1.3.6.1.4.1.12925
.1.3.6.1.4.1.12925 = No Such Object available on this agent at this OID

It knows from the output what MIB it is (attached).
Am I being brain dead again, or?

There's only one entry in snmptt.conf so the MIB is small, but something should show up...

MIB: ThreeParMIB (file:./ThreeParMIB.txt) converted on Thu Oct 8 20:53:36 2015 using snmpttconvertmib v1.3
#
EVENT alertNotify .1.3.6.1.4.1.12925.1.8 "Status Events" Normal
FORMAT Alert notification contains details about an event that $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "Alert notification contains details about an event that $*"
SDESC
Alert notification contains details about an event that
may affect system operations and performance. The
details include all columns defined in alertTable.
Variables:
1: component
2: details
3: nodeID
4: severity
5: timeOccurred
6: id
7: messageCode
8: state
9: serialNumber
EDESC

[SteveBeauchemin]

On this new host...
If you try to walk and grab the following data - it should tell you the OID that is available to exploit.

snmpwalk -t 3 -v 2c -Cc -On -c [community] [device] SNMPv2-MIB::sysObjectID

It may be that the MIB you think you need is not the MIB.
Also, just FYI...The name of the MIB text file is actually meaningless.
What actually matters is the text at the top of the file.
The line that contains DEFINITIONS ::= BEGIN starts with the actual MIB name.

From looking at one of your earlier posts I see this.
--------------
# snmpwalk -v2c -c sp1der txslm2mlapp006.ilo
SNMPv2-MIB::sysDescr.0 = STRING: Integrated Lights-Out 4 2.00 Jul 30 2014
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.232.9.4.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3901337205) 451 days, 13:02:52.05
SNMPv2-MIB::sysContact.0 = STRING:

And on the iLo the 232 was a clue where to go digging. sysObjecID sometimes get you closer to where you need to look.
(actually I think check_*ilo tests from the exchange probably do good stuff and are worth looking at)
--------------

Anyway, that Object ID is telling you what the hardware knows about itself.
There will be other data available if you query .1 - but the vendor specific data is sometimes identified for you via that ID.

Also, just because that MIB only exports one Trap definition does not mean it doesn't have a ton of other data inside waiting for you to discover.

Plan to be surprised by stuff in SNMP data.
You do not always get what you think from different pieces of hardware.
And the vendor OID may not always expose the inner working that you want insight on.

Steve B

[gormank]

Not sure why you're hung up on the filename. If an snmpwalk on the numeric oid returns the mib name and that matches the mib file, there's no issue.

# grep DEFINITIONS /usr/share/snmp/mibs/ThreeParMIB.txt
ThreeParMIB DEFINITIONS ::= BEGIN

A walk on the oid gives the name of the mib:

# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 1.3.6.1.4.1.12925
ThreeParMIB::threepar = No Such Object available on this agent at this OID

Yes, I know the MIB is in the file named ThreeParMIB but the internet also says the OID is enterprises.12925

A walk on OID.n produces the same nothingness as above.

snmpwalk -t 300 -v 2c -Cc -On -c sp1der txslm2mfchp001 1.3.6.1.4.1.12925.1
.1.3.6.1.4.1.12925.1 = No Such Object available on this agent at this OID

[SteveBeauchemin]

try this...

# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 SNMPv2-MIB::sysObjectID

[tgriep]

Let us know if it works for you.

[gormank]

Steve,
Yes that works, but its on the brocade, not the 3par. I can walk the brocade, not the 3par. Still working on the latter.

# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 SNMPv2-MIB::sysObjectID
SNMPv2-MIB::sysObjectID.0 = OID: SW-MIB::sw

Thanks

[SteveBeauchemin]

so
snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 1.3.6.1.4.1.12925
gets you nothing

but
snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 SNMPv2-MIB::sysObjectID

gets you SW-MIB::sw

Which I translate into .1.3.6.1.4.1.1588.1

so what does
snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 1.3.6.1.4.1.1588
give you.

As for the 3par. Does it have the same host name as the Brocade? Is it an add on module plugged into the brocade?

Steve B

[gormank]

Sorry, the 3par is a storage system 3prf (12925). Above I showed snmpwalk on the wrong host. The fchp are the fiber switches (1588).

Plenty of OIDs for the switch so we're good ther.
# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2mfchp001 1.3.6.1.4.1.1588 | wc -l
15368

Nada for the storage.
# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2m3prf001 1.3.6.1.4.1.12925
ThreeParMIB::threepar = No Such Instance currently exists at this OID

Its interesting (to me) that it converts ....12925 to ThreeParMIB.threepar , 0 to threepar.0, and 1 to inserv.1, but doesn't list OIDs.
# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2m3prf001 1.3.6.1.4.1.12925.0
ThreeParMIB::threepar.0 = No Such Instance currently exists at this OID
# snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2m3prf001 1.3.6.1.4.1.12925.1
ThreeParMIB::inserv = No Such Instance currently exists at this OID

In looking at the previous few lines and the MIB, it seems the OIDs are implied on lines beginning with ::=.
So for most MIBs , I could use enterprises.232/1588, etc but enterprises.12925 (seemingly the same as 1.3.6.1.4.1.12925) is no good.
From the below info I would think that enterprises.12925.1.4 would give me whatever inservAgentCaps is. But my logic seems incorrect.

inservAgentCaps OBJECT-IDENTITY
STATUS current
DESCRIPTION "InServ agent profile"
::= { inserv 4 }

# grep ::= /usr/share/snmp/mibs/ThreeParMIB.txt
ThreeParMIB DEFINITIONS ::= BEGIN
::= { enterprises 12925 }
ThreeparLongDisplayString ::= TEXTUAL-CONVENTION
::= { threepar 1 }
::= { inserv 4 }
::= { inserv 7 }
::= { alertTable 1 }
AlertEntry ::= SEQUENCE {
::= { alertEntry 1 }
::= { alertEntry 2 }
::= { alertEntry 3 }
::= { alertEntry 4 }
::= { alertEntry 5 }
::= { alertEntry 6 }
::= { alertEntry 7 }
::= { alertEntry 8 }
::= { alertEntry 9 }
::= { alertEntry 10 }
::= { inserv 8 }
::= { inservAgentCaps 1 }

[SteveBeauchemin]

On the storage try a shorter less specifc oid query. whenever I get nothing, I always shorten the oid until it gives me something.

snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2m3prf001 1.3.6.1.4.1
See if you get a list.

Or you can at least prove it is alive by asking for something non vendor specific, like maybe some basic info.
This should prove the credentials are working.
snmpwalk -t 300 -v 2c -Cc -m ALL -c sp1der txslm2m3prf001 .1.3.6.1.2.1.1.1.0

Or better yet, let it tell you the OID it considers to be its identity. Get the numeric output for the sys object id
snmpwalk -t 300 -v 2c -Cc -On -c sp1der txslm2m3prf001 SNMPv2-MIB::sysObjectID

It may not give up the 12925. It may have something else in mind.

But it should at least give something to one of these examples. At least prove it can provide SNMP output in some form.

Whatever it gives you is what I would try to exploit.

BTW - the failed snmp queries where it give you the output - comes from snmpwalk and not your device under test.

Steve B

[ssax]

gormank, SteveBeauchemin's is right, that OID might not be available, it's just an the enterprise, try the walk like he said and see if it will give you the information you are looking for.

Let us know how it goes, thank you.