@MarkRH @RMerlin
This change in rstats.c seems to be the cause for the 4GB spikes
https://github.com/RMerl/asuswrt-me...3182da5#diff-ad1905e5fc69da7fa5328b342764d36e
specifically these lines
https://github.com/RMerl/asuswrt-me.../release/src/router/rstats/rstats.c#L937-L948
Asus seems to be doing extra calculations for certain models (RTCONFIG_BCMARM); the statements in the else blocks are especially weird as vlan_{tx,rx} aren't actually used anywhere else.
Code:
counter[0] = counter[0] + 0xffffffff - vlan_rx;
The 0xffffffff is where the 4GB figure comes from.
It is also weird that
@MarkRH mentions the official firmware 384_20624 does not exhibit this issue, while this is in the GPL archive for that release which Merlin merged.
My current theories are:
- Asus firmwares do not line up with their GPL archives perfectly ie. what they used to compile the firmware is slightly out of sync with their GPL releases.
- These weird calculations are for upcoming changes to how traffic is calculated ie. Broadcom drivers would post aggregated numbers to /proc/net/dev, and rstats has to separate WAN from LAN.
- These code changes to rstats.c seem pretty isolated and should be safe to revert?
This seems like a band-aid fix for another programming error or design flaw (by Broadcom), not to mention introducing an integer underflow.