SNMP Uptime is not real

digidax

Hi,

with SNMP I get from pfsense this uptime:

# snmpget -v1 -c public 192.168.1.1 .1.3.6.1.2.1.25.1.1.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (273429777) 31 days, 15:31:37.77

but on pfsense shell I get this (what is real):

[2.0.1-RELEASE][root@mydomain]/root(5): uptime
11:40AM  up 1 day, 17:37, 2 users, load averages: 0.00, 0.00, 0.00

What's the problem with the SNMP request? Do I use the wrong OID ".1.3.6.1.2.1.25.1.1.0" but the MID handle it as SystemUptime.

best regards
Frank

jonallport

Mine match (within the marhin off error expected when swapping from browser to SSH to MIB reader):

SNMP MIB .1.3.6.1.2.1.25.1.1.0:
Name/OID: .1.3.6.1.2.1.25.1.1.0; Value (TimeTicks): 387 hours 6 minutes 28 seconds (139358841)

Dashboard:
16 days, 03:08

Bash 'uptime':
12:29PM up 16 days, 3:07, 2 users, load averages: 0.17, 0.08, 0.02

jimp

What about this oid:

$ snmpget -On -v2c -c public 192.168.x.x system.sysUpTime.0
.1.3.6.1.2.1.1.3.0 = Timeticks: (4162536) 11:33:45.36

I can never remember which is which, but one of them tracks the system uptime, the other tracks how long the snmp daemon has been running.

For many, those two would be about the same, but it would reset when making changes to the SNMP daemon settings.

jonallport

Name/OID: .1.3.6.1.2.1.1.3.0; Value (TimeTicks): 340 hours 16 minutes 14 seconds (122497403)
Name/OID: .1.3.6.1.2.1.25.1.1.0; Value (TimeTicks): 510 hours 7 minutes 9 seconds (183642985)
Uptime: 21 days, 06:07 (510 hrs 7 mins)

According to my loaded MIBs:

Name sysUpTime!@#.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime
OID .1.3.6.1.2.1.1.3
Descr The time (in hundredths of a second) since the network management portion of the system was last re-initialized.

Name hrSystemUptime!@#.iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime
OID .1.3.6.1.2.1.25.1.1
Descr 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.

If memory serves, I changes the trap destination about 2 weeks ago (340 hours-or-so), that would've re-started the snmp daemon.