[mrtg] Is there a way around the 32 bit wrap-around?

[Michael Strecke]

I'm using the "NetCologne Premium Modem" – which seems to be a
rebranded  Sphairon Turbolink.  The device is not SNMP capable, but you
can query status information via UPnP.   

I'm using ng-upnp2mrtg.py to retrieve the values of 
“NewTotalBytesReceived“ and “NewTotalBytesReceived”, which are then
reported to mrtg.  That works fine.

However, these values are being reset to 0 when the link is terminated,
which happens twice a day (policy of my ISP).  I can re-connect
immediately, but it leaves a nasty peak in the mrtg log file and the graph.

Yes, it's the 32 bit wrap-around – again.

And someone on this mailing list suggested to use MaxBytes1/2 to
suppress these peak values. With increasing line speeds this becomes
more and more difficult. With a sampling interval of let's say 5 minutes
the speed you need to get 2^32 bytes within this time frame is:

     2^32 * 8 / (5 * 60) = approx. 109 Mbit/s

My fiber optic connection has a nominal speed of 100/10 Mbit/s (down/up).

Granted, I haven't seen it at full speed, yet. But it becomes clear that
the MaxBytes solution is a work-around, not a fix. A work-around that
becomes increasing unreliable.

I am wondering if there is a way to make mrtg ignore values that are not
larger than the previous one for the next speed calculation? It still
needs it to compare it with the value after that....
Or is there a way to force a 64 bit wrap-around?

Some googleing showed that the problem is not new.  What is the reason
behind not implementing a configuration option for this? Or did I miss it?

Mike