Re: Cacti on 7.9

On 2026-07-21, Steven Surdock <[email protected]> wrote:
> There is an indication that the value returned by OBSD for SNMP-FRAMEWORK-MIB::snmpEngineTime.0 is incorrect.  On my discussion on the Cacti forum, https://forums.cacti.net/viewtopic.php?p=297860&sid=1a77491941fff1bd5572c5334095913b#p297860, it was brought up that "the SNMP-FRAMEWORK-MIB::snmpEngineTime.0 object is designed to track the operational status of an SNMP engine. It specifically measures the time elapsed since the last change in the snmpEngineBoots value."  However, OBSD is returning wall clock time.  This is causing some confusion with the Cacti poller.
>
> Media$ snmpget -v2c -c public localhost snmpEngineTime.0
> SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 1784666833 seconds
>
> Media$ date +%s
> 1784666836
>
> https://github.com/Cacti/cacti/issues/7342

snmpEngineTime can't be used as a proxy for *system* uptime anyway
because when implemented normally, it just relates to uptime of the
SNMP engine, not the whole system.

Reasoning for snmpd's non-standard use of snmpEngineTime is explained
here in snmpd.c:

u_long
snmpd_engine_time(void)
{
        struct timeval   now;

        /*
         * snmpEngineBoots should be stored in a non-volatile storage.
         * snmpEngineTime is the number of seconds since snmpEngineBoots
         * was last incremented. We don't rely on non-volatile storage.
         * snmpEngineBoots is set to zero and snmpEngineTime to the system
         * clock. Hence, the tuple (snmpEngineBoots, snmpEngineTime) is
         * still unique and protects us against replay attacks. It only
         * 'expires' a little bit sooner than the RFC3414 method.
         */
        gettimeofday(&now, NULL);
        return now.tv_sec;
}

This didn't change since snmpEngineTime support was added alongside
SNMPv3 in 2012 so any recent problems are presumably due to tripping
over some maximum value of a data type recently.

(There could be issues with false replay detection with the current
scheme if the clock skewed backwards, I believe).

Fixing this would require snmpd to write to persistent storage.

-- 
Please keep replies on the mailing list.