Mt76 wireless driver debugging

For Developers
159

I understand that, but my point is that @daniel posted this some days ago:

But @Brain2000 and I raised questions specifically around the statement of "In both cases you also need to switch on hardware flow offloading..." because documentation for WED seems to state SW/HW offloading is not required.

So, my question back to @daniel was meant to clarify, if you enable the HW & SW offloading options in /etc/config/firewall, then what, besides the firewall service, would care about those settings? Hence, does the firewall service itself need to be running? Does bridger look for those settings?

I was just trying to get to the bottom of the reasoning from @daniel's perspective, given his expertise at the code level of much of this. And he confirmed the answer here:

160

I do have this module installed:
kmod-nft-offload - 5.15.108-1

root@AP-Office:~# lsmod | grep -E nft.*offload
nf_conntrack           90112  7 nft_redir,nft_nat,nft_masq,nft_flow_offload,nft_ct,nf_nat,nf_flow_table
nf_flow_table          32768  4 nf_flow_table_ipv6,nf_flow_table_ipv4,nf_flow_table_inet,nft_flow_offload
nf_tables             163840 24 nft_fib_inet,nf_flow_table_ipv6,nf_flow_table_ipv4,nf_flow_table_inet,nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet,nft_reject,nft_redir,nft_quota,nft_objref,nft_numgen,nft_nat,nft_masq,nft_log,nft_limit,nft_hash,nft_flow_offload,nft_fib_ipv6,nft_fib_ipv4,nft_fib,nft_ct,nft_counter,nft_chain_nat
nft_flow_offload       16384  0

But I still see this when I start the FW service:

root@AP-Office:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option flow_offloading '1'
	option flow_offloading_hw '1'

root@AP-Office:~# /etc/init.d/firewall start
Hardware flow offloading unavailable, falling back to software offloading
161

This packet? (my router Linksys E8450 (UBI))
bridge 1.7.1-1 10.96 KiB Manage ethernet bridging: a way to connect networks together to…

162

Bridger is only available for development builds.

2 Likes
163

For anybody building their own snapshot firmware who wishes to look at the debug info for Bridger, I have enabled debug output on my fork. You can pull the debug enabled code by using this patch:

Updated patch process here:

On a debug enabled build, you can stop the Bridger service, then execute the /usr/sbin/bridger binary explicitly. The debug info is placed into stderr, so you will see it scrolling on your terminal as long as Bridger is running.

FWIW, I am running it like so:
/usr/sbin/bridger 2>/tmp/bridger_log

In this way, I can tail -f /tmp/bridger_log and potentially filter (via grep) the log without having to keep starting and stopping the Bridger binary.

I am providing this just to help those who are troubleshooting Bridger/WED, or just gaining a better understanding of how it works. I am not taking over support for Bridger by any means.

If you wish to enable the log as part of the service (while troubleshooting), you can modify the start_service() function in /etc/init.d/bridger as such:

start_service() {
        procd_open_instance
        procd_set_param command /bin/sh -c "$PROG 2>/tmp/bridger_log"
        procd_set_param respawn
        procd_close_instance
}

Opened an issue for a discrepancy I see in VLAN handling. Not calling it a legit problem at this point, but raising it for awareness and confirmation:

1 Like
164

FYI, I updated the patch I linked in Pastebin. Instead of having to switch over to my Bridger fork, you can stick with Felix's source and run the following in your OpenWrt build system to apply the updated patch to turn on debug output:

mkdir package/network/services/bridger/patches && curl -o package/network/services/bridger/patches/001-enable-debug-output.patch https://pastebin.com/raw/5TY3hema

Otherwise, refer to my prior post for ways you can output the debug info once you build from this patch.

1 Like
166

@Brain2000 FYI, I am also running with these patches included in my build and no negative side-effects noticed as of yet.

$ ls -l package/kernel/mt76/patches/
-rw-r--r-- 1 user user  769 May  3 14:19 0001-wifi-mt76-mt7915-fix-background-radar-event-being-bl.patch
-rw-r--r-- 1 user user 7705 May  3 14:19 0002-wifi-mt76-mt7915-Update-beacon-size-limitation-for-1.patch
-rw-r--r-- 1 user user 8526 Apr 29 13:05 0003-wifi-mt76-mt7915-disable-wfdma-tx-rx-during-SER-reco.patch
-rw-r--r-- 1 user user 1019 May  3 14:52 0004-wifi-mt76-mt7915-fix-the-beamformer-issue.patch

I picked them up from here:
https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+log/add8de6b4a5ad54db72c31fc05a1e38600438b7f/autobuild_mac80211_release/package/kernel/mt76/patches

Have not yet updated to it, but a new version of bridger was released:

Will update this post with any feedback after updating and testing.

4 Likes
167

There are some interesting attempts at simplifying the (mac80211 and cfg80211 related) locking code, which might drastically reduce the need for locks in wireless drivers like mt76.

See here:

5 Likes
168

Would more of the fixes discussed in this thread be part of this commit to snapshot?

commit f7665a0f1a2da63e2046119c0c3de578f16651ce
Author: David Bauer <mail@david-bauer.net>
Date:   Wed May 17 20:37:21 2023 +0200

    mt76: update to latest HEAD

Edit... snapshot seems not to be great yet:

169

I am running with snapshot 4e5aac472935ce3ba3abc9bd72b880951843092b (the one with the bridger update) and did not have to reboot my rt3200 since more than a week.
Before this bridger update I had to reboot more frequently (sometimes daily), in particular with more wifi STAs.
The RT3200 are APs with bridger installed and enabled (even though WED is off right now) and they do have vlans.

Edit: had to reboot again, but still seems to be needed less frequently.

1 Like
170

@Brain2000 Have you seen this yet?

171

@rany are you rany2 from github? I see you have been running wifi: mt76: mt7915: fix the beamformer issue for a few weeks/months now. I am curious. Is it any good? Could you provide feedback why this commit (and some others in your tree) have not been pushed upstream or into the mt76 repo?

1 Like
172

@Brain2000 Wonder if this is the silver bullet:

173

@Brain2000 Also just noticed this as well:

Building now and will give WED another go! :slight_smile:

174

I'm going to give the new build a while to cook before I cast any feedback one way or another.

In the meantime, I just noticed this:

Specifically:

Query the status of WED

To see which flows are actually getting off-loaded. This command works only for router mode (not AP):

# cat /sys/kernel/debug/mtk_ppe/bind
01dd0 BND IPv4 5T orig=xxx:11068-10.1.10.241:33328 new=xxx:11068-10.1.10.241:33328 eth=xx:xx:xx:xx:xx:xx-xx:xx:xx:xx:xx:xx etype=0008 vlan=0,129 ib1=21403a8d ib2=007e0060

The verbiage, "This command works only for router mode (not AP)", is new to me. Anyone know when this was added to the E8450 TOH page?

175

It's also not true at all. WED works well with bridged AP if you install the bridger package.

176

@lukjod Can we please confirm the validity of this update?

In particular, the addition of this verbiage: "This command works only for router mode (not AP)"

177

I sure am scratching my head around WED again. It doesn't work consistently for me. For example, if I restart bridger and then immediately begin an iperf3 test with another LAN host on my network, I see a flow appear in /sys/kernel/debug/ppe0/bind for the length of the "download" to my iperf3 [wireless] client machine. Once the iperf3 completes, I will run it again with the exact same arguments and the flow does not show up in /sys/kernel/debug/ppe0/bind.

I find the above behavior happening again and again, but even with other STAs doing normal internet traffic. It just is inconsistent, at best.

Can you confirm if what I'm describing is an anomaly or if I'm actually seeing "correct" behavior?

1 Like
178

Yes . There is even reported issue bridger is not reliable (fails to register traffic) · Issue #3 · nbd168/bridger (github.com)
Now I'm using 23.05 but since mt76 driver drifted away in master builds I might switch to master as well.

1 Like
179

In case you haven't seen it yet, check out rany2's finding here:

cc: @Brain2000 && @daniel

2 Likes