This is supporting formation for this sourceforget bug report:
SNMP Version 1: If I try to SNMP get two OIDs:
- one of which doesn't exist
- the other being in numerical
.1.3.6.1.4.1.123456.1
format
like this:
my $vars = new SNMP::VarList(
[
# enterprises.123456.1.0 - Some bogus OID
'.1.3.6.1.4.1.123456.1', 0
], [
# This ifIndex doesn't actually exist
'ifIndex', 10000
],
);
$sess->get($vars)
Then Net-SNMP returns this in $sess
:
ErrorStr: (noSuchName) There is no such variable name in this MIB.
ErrorInd: 2
and replaces the numerical OID with a symbolic one (enterprises.123456.1.0
in the example).
When I remove the 2nd OID like so:
splice @$vars, $sess->{ErrorInd} - 1, 1;
And try again. Then I get this:
ErrorStr: Unknown Object Identifier (Sub-id not found: (top) -> enterprises)
So Net-SNMP replaced my numerical OID with one it doesn't understand itself? I therefore file a bug...
Here is a some reproducing code along with some sample output.
We start out with tese two OIDs:
.1.3.6.1.4.1.123456.1.0
- An OID for which there is no MIB fileifIndex.10000
The ifIndex.10000
is last, because testing shows that the Net-SNMP agent (localhost) will give a noSuchName
error with ErrorInd
pointing that least OID.
I started out with the first OID being a real valid OID in numerical form. So it doesn't matter whether there is a mib for the first OID or not.
Use UseLongNames => 1
in the $sess
object.
or
When the OIDs come back with an noSuchName
error, replace the OIDs with the
ones from the original set. I.e. replace the enterprises... with .1.3.6... And
then splice and try again. Then it works.
Linux with libsnmp-perl 5.4.1~dfsg-12