Error on interpretation of snmpUtime, when to big

[arno-st]

On a device when uptime is to long (more than 224 days I think) the device is seen as down, if the monitoring is set to snmpUptime and ping.

As an exemple I have this:
Uptime: 4190934469 (485days, 1hours, 29minutes)
and device is down.
ON 1.2.18 I have this:

sre-core	10.0.2.26	3159	28	29	Down	2d:23h:56m	N/A

And on 1.2.17

sre-core	10.0.2.26	363	37	38	Up	226d:23h:49m	485d:1h:55m

[netniV]

This may be the difference between 32-bit and 64-bit uptime counters. Uptime is recorded in seconds if I remember rightly as I used to have this issue on older 32-bit hardware making Cacti think it had rebooted when it hadn't.

What is your OS/Arch for all involved systems?

[arno-st]

My 1.2.18 run on centos 10.0-1160.42.2.el7.x86_64

My 1.2.17 run on centos 10.0-1160.42.2.el7.x86_64

The only point can find is that on has PHP 7.4.2 on the 1.2.17 version, the other one has 7.4.14 where cacti 1.2.18 run.

Otherwise, it should be same same!

As for the client I'm polling there are both the same device Cisco Switch

[netniV]

What about the SNMP libraries? Are you using php-snmp or net-snmp?

[arno-st]

php-snmp
both same version
Name : php-snmp
Arch : x86_64
Version : 7.4.24
Release : 1.el7.remi

[arno-st]

Don't think the problem is on the polling part.
since the DB give me both:
cacti 1.2.17 4165077143
cacti 1.2.18 4192683188

Mineur difference.

[TheWitness]

I think we need to move that column to a bigint later tonight my time unless @netniV want's to hammer it out.

[TheWitness]

Okay, this is resolved for the 1.2.19 release. You can just hand run the two SQL alters at the bottom of the 1_2_19.php file if you want to hack it in.

[TheWitness]

Thanks for keeping your eye on the ball.