Integer Overflow in totalbytessent → InfluxDB Write Error

[tobschndr]

Description:
When writing FritzBox stats to InfluxDB, an error occurs if the value of totalbytessent exceeds the maximum range of int64. InfluxDB only accepts integers up to 9223372036854775807.

ERROR: Failed to write to InfluxDB '192.168.xx.yyy': 400: unable to parse 
'fritzbox,box=fritz.box totalbytessent=18446743988672050869i 1751621564000000': 
unable to parse integer 18446743988672050869: strconv.ParseInt: parsing "18446743988672050869": value out of range

Steps to Reproduce:

1. Run the latest bb-Ricardo/fritzinfluxdb container
2. Use a FRITZ!Box with unusually high totalbytessent values
3. Attempt to write stats to InfluxDB

Cause:

The FRITZ!Box sometimes returns very large values (likely uint64) for totalbytessent. These are inserted into the InfluxDB line protocol without any range validation. Since InfluxDB expects int64 values, this causes a parse error.

Suggested Fix:

Add a value check before writing to InfluxDB:

MAX_INT64 = 9223372036854775807
if total_bytes_sent 
System Information:

• Container: fritzinfluxdb (latest version)
• Python version: 3.10
• InfluxDB version: 1.8.10
• FRITZ!Box model: 6591 Cable (FRITZ!OS **8.10-122506 BETA**)

Thanks for the great project! A small patch to prevent this overflow would be very helpful.

[tobschndr]

With adaption of the handler.py I was able to get it working again. If not changing the header.py, the container would not write any data to my InfluxDB.

class InfluxHandler:
    overflow_warned = set()
    last_totalbytessent = None

    def convert_measurement(self, measurement):
        MAX_INT64 = 9223372036854775807

        if measurement.name == "totalbytessent":
            value = measurement.value
            # Clamp
            if isinstance(value, int) and value >= MAX_INT64:
                value = MAX_INT64
            # Check for overflow or reset
            if self.last_totalbytessent is not None and value < self.last_totalbytessent:
                # Counter wurde zurückgesetzt oder capped, optional: loggen
                # Option 1: Setze Wert auf None, wird nicht geschrieben
                return None
                # Option 2: Setze Wert auf den letzten Wert
                # value = self.last_totalbytessent
            self.last_totalbytessent = value
        else:
            value = measurement.value

        return {
            "measurement": self.config.measurement_name,
            "tags": measurement.tags,
            "time": measurement.timestamp,
            "fields": {measurement.name: value}
        }

this is what my Grafana shows me after "patching" the original handler.py But I am not sure if this solution is very sustainable...?

[bb-Ricardo]

Hi,

this looks like a duplicate of #137.

Yes, I guess this is at least a mitigation. But this also means that totalbytessent will stop being updated and report 0 from that point on. But We could log this issue and recommend a FritzBox reboot. What do you think? how log is your Box up now?

[tobschndr]

Hi,

thanks for responding so quickly 😎

Initially, I thought the issue was something else, especially since my FritzBox rebooted this morning after being updated to the latest version. However, after doing another manual reboot this evening and recreating the Docker container in parallel (to restore the defaults), it seems to be working fine again. So, it turns out your assumption was correct 😄

[tobschndr]

Sad news, the issue is not fixed with having the reboot 😢 it took some time to establish the primary connection. The moment I wrote my closing of the issue, the LTE-USB-Stick was used (until the primary connection is available).

The Container error log again states these lines:

INFO: Successfully parsed config INFO: Connection to InfluxDB v2.7.12 established and bucket is present INFO: Successfully established FritzBox TR-069 session INFO: Successfully established FritzBox Lua session INFO: Successfully connected to FritzBox '192.168.xxx.y' (fritz.box) Model: FRITZ!Box 6591 Cable (Cable) - FW: 8.10 INFO: Starting main loop INFO: Service 'DSL Info (Fritz!OS 7.29 - latest)' not applicable for this FritzBox Model Link type 'Cable' ERROR: Failed to write to InfluxDB '192.168.xx.yy': 400: unable to parse 'fritzbox,box=fritz.box totalbytessent=18446744040540660192i 1751704032000000': unable to parse integer 18446744040540660192: strconv.ParseInt: parsing "18446744040540660192": value out of range ERROR: Failed to write to InfluxDB '192.168.xx.yy: 400: unable to parse 'fritzbox,box=fritz.box totalbytessent=18446744040540660192i 1751704032000000': unable to parse integer 18446744040540660192: strconv.ParseInt: parsing "18446744040540660192": value out of range ERROR: Failed to write to InfluxDB '192.168.xx.yy': 400: unable to parse 'fritzbox,box=fritz.box totalbytessent=18446744040540660192i 1751704032000000': unable to parse integer 18446744040540660192: strconv.ParseInt: parsing "18446744040540660192": value out of range

[bb-Ricardo]

Hi, even after s restart? With witch value does the counter start after a reboot?

[tobschndr]

I had to manually reset the statistics (but did not notice the values before doing so), then rebooted the FritzBox once again. In fact, it seems to work now - my assumption is that having the latest BETA installed might influence this counter (before it worked without issues) 🙄

[tobschndr]

After the latest update to FRITZ!OS: 8.10-122836 BETA the counter issue is finally fixed from AVM side 😃

[bb-Ricardo]

Hi, this is good news. So now the counter is behaving normally again and returns sane values?

[tobschndr]

Yes. Looks as expected again.