Bridger is only available for development builds.
2 Likes
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
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
@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
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
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:
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
@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
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?
It's also not true at all. WED works well with bridged AP if you install the bridger package.
@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)"
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
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
Not sure how many people are still tracking this thread. For those who are, you might be interested to know there is a newer mt7915 firmware out in the wild. I'm just now testing it myself, so I can't vouch for its stability.
If you're able and willing to take on the risk yourself, you can find the firmware files here.
[ 7.962496] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20231018150711a
[ 8.079564] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20231018150743
[ 8.116478] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20231018150804
Previous firmware I was using...
Summary
[ 8.138573] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20230418151304a
[ 8.331298] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20230418151336
[ 8.406441] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20230418151358
4 Likes
Firmware included in 23.05.2 is still from 2022:
[ 6.881143] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20220929104113a
[ 7.035991] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20220929104145
[ 7.085219] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20220929104205
1 Like
Interesting... 
I wonder why the default firmware continues to lag so far behind at this point.
FWIW, I have not had any adverse effects on the 20231018* firmware thus far.
1 Like