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.

Reply via email to