Template:FAQ:Applications 09

Assuming that you do have access to this object, the most likely cause is forgetting the instance subidentifier.

If you try walking the 'system' group (or any other part of the MIB tree), you should notice that all of the results have a number after the object name. This is the "instance subidentifier" of that particular MIB instance.

For values in tables (such as the sysORTable), this acts as an index into the table - a very familiar concept. But all SNMP values will display an instance number, whether or not they are part of a table. For non-table objects ("scalars"), this instance subidentifier will always be '.0', and it must be included when making a GET request.

Compare the following:

  $ snmpget -v1 -c public localhost sysUpTime
  Error in packet
  Reason: (noSuchName) There is no such variable name in this MIB.
  This name doesn't exist: system.sysUpTime
  
  $ snmpget -v1 -c public localhost sysUpTime.0
  system.sysUpTime.0 = Timeticks: (69189271) 8 days, 0:11:32.71
 

This is a little less obscure when using SNMPv2c or v3 requests:

  $ snmpget -v 2c -c public localhost sysUpTime
  system.sysUpTime = No Such Instance currently exists