in reply to Net:SNMP get_table() method failing

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

[download]

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

[download]
.. 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.

Replies are listed 'Best First'.
Re^2: Net:SNMP get_table() method failing
by McDarren (Abbot) on Oct 31, 2006 at 10:29 UTC
    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

    [download]
    (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

    [download]

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

[reply]
[d/l]
[select]
      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.

[reply]
[d/l]

In Section Seekers of Perl Wisdom