Feature Request: Make touchscreen traffic graph work with flow offloading enabled (GL-BE3600 / Slate 7)
Hi GL.iNet team,
The live traffic graph on the Slate 7's touchscreen is a great feature, but it currently shows "traffic not available" whenever flow offloading (hardware OR software) is enabled. This forces users to choose between two things they should not have to choose between: real-time throughput visibility on the display vs. the performance gains of offloading.
Why this happens (as far as I can tell):
The display daemon appears to read its byte counters from the Netfilter/conntrack path. With flow offloading active, only the first packet of a connection traverses that path - all subsequent packets bypass it via the fast path, so the counters effectively stop incrementing for established flows. Result: the display has no usable data and shows "not available."
Proposed solution:
Switch the display daemon's data source to per-interface driver counters, e.g. /sys/class/net//statistics/rx_bytes and tx_bytes (or the equivalent via ip -s link, ethtool -S, or rtnetlink). These counters sit below the offload fast path in the driver layer and continue to increment correctly regardless of whether offloading is active.
The display only needs aggregate WAN throughput in bytes/sec, so reading deltas from the WAN interface counter every second would give the exact same visual result without depending on conntrack accounting.
Why this matters:
-
The Slate 7 is marketed with real-time speed monitoring as a key touchscreen feature
-
Network acceleration is on by default, which means most users see "not available" out of the box without understanding why
-
On a quad-core A53 @ 1 GHz, fully disabling offloading is a real performance penalty, especially with many clients or multi-gigabit WAN — users should not have to accept that just to see a number on the display
-
Other GL.iNet models with touchscreens (Slate 7 Pro, future models) would benefit from the same fix
A small change in the display daemon's data source would resolve this cleanly. Is this something the firmware team would consider for an upcoming 4.x release?
Thanks for the great hardware — happy to test a beta build if it helps.
System info:
-
Device: GL-BE3600 (Slate 7)
-
Firmware: 4.8.3 (release, 2026-01-31)
-
OpenWrt: 23.05-SNAPSHOT
-
Kernel: 5.4.213