SNMP – Resolving hrSystemUptime.0 Unknown Object Identifier

alpinedockersnmp

I get the error in the title when I issue the following command.

$  snmpget -v3 -u edgeos-snmpd-user -l authPriv -a SHA -x AES -A authPhrase -X privPhrase 192.168.x.x hrSystemUptime.0
hrSystemUptime.0: Unknown Object Identifier (Sub-id not found: (top) -> hrSystemUptime)

If I enter the same command on the target system (192.168.x.x), I get a valid result.

# snmpget -v3 -u edgeos-snmpd-user -l authPriv -a SHA -x AES -A authPhrase -X privPhrase localhost hrSystemUptime.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (1362660) 3:47:06.60

The client is an Ubuntu 18.04.1 based Docker container and the target is an Alpine-based Linux device.

I have installed snmp-mibs-downloader in the container and the hrSystemUptime entry exists in "/var/lib/snmp/mibs/ietf/HOST-RESOURCES-MIB.

-- The Host Resources System Group

hrSystemUptime OBJECT-TYPE
    SYNTAX     TimeTicks
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The amount of time since this host was last
        initialized.  Note that this is different from
        sysUpTime in the SNMPv2-MIB [RFC1907] because
        sysUpTime is the uptime of the network management
        portion of the system."
    ::= { hrSystem 1 }

However, it doesn't seem to be searching this directory.

$ net-snmp-config --default-mibdirs
/home/edge/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp

I copied HOST-RESOURCES-MIB to /home/edge/.snmp/mibs but it made no difference.

What do I have to do in the container to get this to work?

Best Answer

The snmp package installs /etc/snmp/snmp.conf:

# As the snmp packages come without MIB files due to license reasons, loading
# of MIBs is disabled by default. If you added the MIBs you can reenable
# loading them by commenting out the following line.
mibs :

Commenting out the last line resolves problem as described by the comment in the file. Removing snmp.conf entirely has the same effect.