FRITZ!Box: use 64-bit traffic counters if available

[mbunkus]

The current FRITZ!Box check uses traffic counters that are 32-bit wide. This means that they overflow quickly, causing gaps in graphs & wrong traffic stats in general. Most current FRITZ!Box models also send additional 64-bit counters. These can & should be used if they're present, which is what this fix implements. If they're not available, the old 32-bit counters are used.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[mbunkus]

I have read the CLA Document and I hereby sign the CLA or my organization already has a signed CLA.

[mbunkus]

recheck

[Yogibaer75]

I think this change will give an error with the tests.
The changed line should look like this.

            interfaces.Counters(
                in_octets=int(
                    section.get(
                        "NewX_AVM_DE_TotalBytesReceived64", section.get("NewTotalBytesReceived", 0)
                    )
                ),
                out_octets=int(
                    section.get("NewX_AVM_DE_TotalBytesSent64", section.get("NewTotalBytesSent", 0))
                ),
            ),

It is not a syntax problem only formatting^^
All the tests are running as expected.
But these tests should later than also be extended to reflect the new counters.

[mbunkus]

Right, I hadn't looked into tests at all. Honestly this was just supposed to be a reminder to the devs to fix the issue upstream & an idea how to fix them. After unsuccessfully fighting with the CLA bot here I just cannot be bothered looking into having to set up tests, too.

[github-actions]

This PR is stale because it has been open for 14 days with no activity and the Github Actions are not passing.

[github-actions]

This PR was closed because it has been inactive for 14 days since being marked as stale.

[martinhv]

I asked my colleague to take a look at the CLA bot

[englertor]

I'm sorry that you are struggling with the CLA bot. So far I can see nothing suspicious in the execution.

Most likely it is that your comment is not literally the required text, but also contains the "recheck". It should work by only including

I have read the CLA Document and I hereby sign the CLA or my organization already has a signed CLA.

in a single comment.

[mbunkus]

The bot literally contained the following in the same reply:

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

Its comment is entirely confusing. If the intent is for the user to post a comment solely consisting of "I have read" without the "recheck", why the additional comment about the "recheck"? 'cause that would imply that it does check each and every comment. Is the "recheck" meant solely for when you edit a comment? Or should I post two comments, one with "I have read…" and one with "recheck"? If not, why is the "recheck" comment there in the first place!?

[mbunkus]

recheck

[englertor]

recheck

[Yogibaer75]

And it's not working ;)

[englertor]

@Yogibaer75 well, the comment of the CLA bot updated and we have the necessary entry in the CLA registry.

Still don't know, why the GH actions didn't pass, but I'm looking into it.

[englertor]

Thanks, @mbunkus for jumping through the hoops to make the CLA bot happy.

Regarding the still failing actions, I've found in the GH logs that it is an issue with how they setup their tests:

HttpError: Unable to retry this workflow run because it was created over a month ago

Apparently, it's not possible to re-run tests that are older than one month as they state in their docs:
https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs

The preferred approach that Github themselves suggest is either a) adding an empty dummy commit or b) if the upstream changes, rebasing on the latest commit.

Given that information, to make the actions run again in this PR you would need to rebase the PR on latest master.

I understand that this is completely bogus.
Therefore I've added the "tracked" label (to prevent the PR going stale) and created an internal ticket to review your changes regardless of the failing tests.

Thank you for your contribution.