McDarren has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

I strongly suspect that the answer to this may be a non-Perl one, but here goes anyway.

I am using Net::SNMP to retrieve configuration data from some remote devices. Some of the data that I am after is in the form of IP ranges, ie. a "starting IP" and an "ending IP".

To pull this data, I've written a small routine which I call each time I need to (once the net::snmp session is established). The routine is as follows:

sub get_ip_list { my $table_index = shift; my $oid = "$base_oid"."$oids{$version}".".$table_index"; my $table = $session->get_table( -baseoid => $oid, ); if (!defined $table) { my $err = $session->error; print "ERROR: $err\n"; return 0; } my $ips; for my $entry (sort keys %{$table}) { my $tail; ($tail = $entry) =~ s/^$oid//; if ($tail =~ m/^\.5\.1\.4\.(\d)/) { $ips->{$1}{start} = $table->{$entry}; } elsif ($tail =~ m/^\.5\.1\.6\.(\d)/) { $ips->{$1}{end} = $table->{$entry}; } } return $ips; }

The above is called as get_ip_list(n), where n represents the SNMP table index to use as a starting point. Mostly, it works fine. However, with certain table indexes the get_table() method returns undef, indicating an error. The error I get is:

ERROR: Received noError(0) error-status at error-index 1

Apart from the fact that I'm not really sure what that error means, I'm also a bit bewildered as to why it's failing in the first place. This is because if I do a manual snmpwalk (via command line) using the same starting OID - I get the expected result. An (edited) example looks something like this:

darren@monitor:~/nomadix> snmpwalk -v1 -c XXXXX B x.x.x.x 1.3.6.1.4.1. +3309.1.4.17 SNMPv2-SMI::enterprises.3309.1.4.17.1.0 = INTEGER: 1 SNMPv2-SMI::enterprises.3309.1.4.17.2.0 = INTEGER: 1 SNMPv2-SMI::enterprises.3309.1.4.17.3.0 = INTEGER: 1 SNMPv2-SMI::enterprises.3309.1.4.17.4.0 = INTEGER: 0 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.2.1 = Counter32: 1 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.4.1 = IpAddress: 61.115.200.69 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.6.1 = IpAddress: 61.115.200.99 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.10.1 = INTEGER: 1

However, when I use the above OID (1.3.6.1.4.1.3309.1.4.17) in my code with get_table() - it fails. I do suspect that this may be a bug in the SNMP implementation of the devices I am querying, but I guess it may also be a problem either with Net:SNMP or my code.

I've tried replacing the line:

my $oid = "$base_oid"."$oids{$version}".".$table_index";
with the hard-coded OID, however this gives the same result. And, as I mentioned above - it works fine with other OID's, so I don't really think the code is the problem.

Can anybody offer any insight or advice?

Thanks,
Darren :)

Replies are listed 'Best First'.
Re: Net:SNMP get_table() method failing
by monarch (Priest) on Oct 31, 2006 at 09:27 UTC
    I have some bad news for you. When you did a walk from 1.3.6.1.4.1.3309.1.4.17 you received 4 scalar objects before you received the table. The scalar objects were numbered:
    SNMPv2-SMI::enterprises.3309.1.4.17.1.0 SNMPv2-SMI::enterprises.3309.1.4.17.2.0 SNMPv2-SMI::enterprises.3309.1.4.17.3.0 SNMPv2-SMI::enterprises.3309.1.4.17.4.0

    The first object that appears to be tabular is

    SNMPv2-SMI::enterprises.3309.1.4.17.5.1.2.1 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.4.1 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.6.1 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.10.1
    .. well 1.3.6.1.4.1.3309.1.4.17.5.1.

    In summary I think you might be missing a digit or two on the OID you provide to the get_table() function.

      hmm, thanks - but no dice I'm afraid.

      I tried modifying my call to the sub to be more specific (skipping the scalars), and inserting a print "OID:$oid\n"; just before the get_table() call. This produced the following output:

      OID:1.3.6.1.4.1.3309.1.4.17.5 ERROR: Received noError(0) error-status at error-index 1 OID:1.3.6.1.4.1.3309.1.4.4
      (there are two separate calls currently - the first fails, the second succeeds).
      I then tried a manual snmpwalk using the OID printed - ie. the same one that was passed to get_table(), which produced:
      snmpwalk -v1 -c XXXXXX x.x.x.x 1.3.6.1.4.1.3309.1.4.17.5 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.2.1 = Counter32: 1 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.4.1 = IpAddress: 61.115.200.69 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.6.1 = IpAddress: 61.115.200.99 SNMPv2-SMI::enterprises.3309.1.4.17.5.1.10.1 = INTEGER: 1

      So, based on the above (and your earlier comments in the CB), I'm fairly convinced now that the problem lies with the get_table() method.

      My next approach will be to investigate using get_next_request instead, as you suggested in the CB. (unless you have any other suggestions? ;)

      Thanks again for your help :)

        It's hard to tell what exactly the problem is without the MIB text and access to the device itself. Plus you've said some indexes return expected results and some don't - adding to the confusion.

        One of my earlier posts (Re^3: Where is the bug in this Net::SNMP code?) shows example code for pulling out tabular objects of a printer MIB. Another even earlier post (Re^3: SNMP from script conflicts with snmpwalk) discusses issues to do with reading tables and ensuring all objects in a table align.

        I've never used get_table myself, it's a relatively new function introduced into Net::SNMP. If you're unsure exactly what the behaviour is of your code then doing it the hard way (like I like to do) may be your best option so you can easily debug.