mirror of
https://github.com/f00b4r0/uspot.git
synced 2026-04-26 06:35:54 +03:00
[GH-ISSUE #45] Bug: Zero Input/Output Octets - SQM-scripts conflict #30
Labels
No labels
bug
enhancement
invalid
invalid
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uspot#30
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nemesifier on GitHub (Sep 12, 2025).
Original GitHub issue: https://github.com/f00b4r0/uspot/issues/45
I noticed that uspot intermittently reports zero traffic accounting data (input/output octets, packets) for all sessions from affected devices, despite actual network traffic occurring. Issue persists until device reboot, the last time I encountered this it required multiple reboots.
Environment
Problem Description
Symptoms
Acct-Input-Octets = 0Acct-Output-Octets = 0Acct-Input-Packets = 0Acct-Output-Packets = 0Acct-Session-Time = 1806)Resolution
Debug Information
Configuration
opkg list-installed | grep uspot:uci show uspot:uci show network:uci show firewall:uci show uhttpd:uci show dhcp:FreeRADIUS Accounting Request
uspot Client Status (
ubus call uspot client_get)Questions for Investigation
Traffic Data Source: How does uspot collect input/output accounting data? (iptables, netfilter, kernel counters?)
Debugging Options: What additional logging or debug options are available to trace traffic accounting collection?
Known Issues: Are there known race conditions or timing issues that could cause traffic counters to stop updating?
Additional Context
Any guidance on enabling additional debugging or known troubleshooting steps would be appreciated.
@f00b4r0 commented on GitHub (Sep 12, 2025):
I see you're attaching uspot to a bridge device, I wonder if there's something at play where the BPF module fails to attach while the bridge is "slow" getting ready. I'll add extra error checking in uspot.
#28 (which you reviewed and sponsored)
You'll need to install
bpftool-minimalin order to investigate the bpf module status (whether it is properly loaded or not) otherwise just hold on until I push the extra error checking / reporting.Off the top of my head, relevant commands would be:
So just to be clear: the traffic counters do not stop updating here, they never started updating at all, right? If so, see my initial comment, otherwise the problem lays elsewhere.
HTH
@nemesifier commented on GitHub (Sep 12, 2025):
Correct, when this happens, traffic accounting is never reported and it shows as 0/0 for both input and output.
@f00b4r0 commented on GitHub (Sep 13, 2025):
@nemesifier I have added some error reporting that may confirm my hunch above, feel free to test current HEAD.
You don't need to rebuild the package, simply take the current
uspot.ucanduspotbpf.ucfiles in https://github.com/f00b4r0/uspot/tree/next/files/usr/share/uspot and dump them on your test device in/usr/share/uspot/, and restart.@nemesifier commented on GitHub (Sep 15, 2025):
I have a device where I can replicate this consistently.
This device does not have WiFi, only ethernet, the traffic will flow through it via ethernet from other WiFi APs in the network.
Rebooting here doesn't seem to work. Accounting traffic always shows zero bytes.
I have done the changes to those two files, what should I look for in the logs?
@f00b4r0 commented on GitHub (Sep 15, 2025):
OK but then why do you use a bridge device there?
any error message prefixed with "uspot"
@nemesifier commented on GitHub (Sep 15, 2025):
It's basically the same hardware without WiFi, so we're testing out the same configuration on both.
Let me try changing it to see what happens without the bridge.
At the moment I don't see any error:
@f00b4r0 commented on GitHub (Sep 15, 2025):
Check at the earliest point in logread. The error message would be printed at uspot startup.
Thanks
@nemesifier commented on GitHub (Sep 15, 2025):
The problem does not appear if the interface is not a bridge.
I restored the bridge configuration to debug the issue, here's the uspot log lines (
logread | grep uspot):@f00b4r0 commented on GitHub (Sep 16, 2025):
Some extra questions:
@nemesifier commented on GitHub (Sep 16, 2025):
x86 target, CWWK Mini PC, (Intel(R) Celeron(R) CPU N2840 @ 2.16GHz)
I will try without RadSec and come back on this.
@nemesifier commented on GitHub (Sep 17, 2025):
Update: it happens also without RadSec, only the uspot config file changes, here's the version without radsec:
Logs:
I don't see any log line related to the logging added in
github.com/f00b4r0/uspot@46e66c1eb0.Here's the output of
ubus call uspot client_get '{"uspot": "captive"}':PS: is there any other log line we can add to get some more info?
@f00b4r0 commented on GitHub (Sep 18, 2025):
Can you check the output of the bpftool commands?
@nemesifier commented on GitHub (Sep 18, 2025):
Sure, I am not familiar with this, what commands should I use or how do I get the output? Thx.
@f00b4r0 commented on GitHub (Sep 18, 2025):
From https://github.com/f00b4r0/uspot/issues/45#issuecomment-3286456620
@f00b4r0 commented on GitHub (Sep 19, 2025):
Also thinking out loud but instead of a reboot, have you tried restarting just uspot (
/etc/init.d/uspot restart)?This would help narrow down the issue if this works.
@nemesifier commented on GitHub (Sep 22, 2025):
Yes, we did try that. The result is not consistent. Sometimes even rebooting doesn't fix it.
I collected the output of
bpftool prog listandbpftool map liston a few devices.I tried this on a few devices.
2 devices that were showing the problem today:
One device which was working fine:
I kept restarting uspot or rebooting a particular device which was showing the issues until the problem went away (in order: first I reboot, then I restarted uspot without reboot, then I rebooted again, only after this sequence the problem went away). Now I ran the commands again on it:
Do you see any significant difference?
@nemesifier commented on GitHub (Sep 22, 2025):
Is there a chance this is an interaction with SQM?
On the device I have with me which only has ethernet and always shows the issue, if I turn off SQM and restart the network stack with
/etc/init.d/network restart, then restart uspot and start a new session, accounting works fine.SQM config triggering this:
@f00b4r0 commented on GitHub (Sep 23, 2025):
Definitely, now that you mention it. Looking at the "piece_of_cake.qos" script you're using, it could certainly interfere with uspot as it deletes root qdiscs upon start. If it restarts after uspot (as it might when the bridge state changes as the bridged interfaces come up), it will wipe the uspot ebpf accounting module. Furthermore it sets a very high priority for the ifb redirection which will also prevent the ebpf module from seeing any inbound traffic.
Forgive me for asking but why would you attach an SQM instance to a bridge interface, and what's more to a lan bridge interface? I'm afraid it makes no sense to me.
@nemesifier commented on GitHub (Sep 23, 2025):
We were applying overall bandwidth limits with SQM when the RADIUS attribute weren't working, then we forgot this piece of config here.
@f00b4r0 commented on GitHub (Sep 23, 2025):
OK but SQM scripts isn't designed to operate on the LAN side, much less on a bridge device. If you want to enforce bw limits on the LAN side you should use dedicated traffic shaping tools instead. Since it is now clear that this is a bug induced by SQM-scripts interaction, I think it can be safely ignored.