it is your 6ghz station ... honestly don't have a clue ... are you using the latest version from @danpawlik ? that should have a couple of settings namely the stationary ap one ...
Hi guys, need your kind help, am confused to follow this thread.
anyone can advice which repository along with branch I have to use to build openwrt image testing BE14 NIC with luci updates.
This would be the simplest route.
EDIT: See below by @danpawlik
in short:
- luci change to see BE has been merged
- firmware 233 has been merged
- updated hostapd has been mergded
- patch for BE wifi scripts has been merged
- something else that does not come to my mind now, but I remember - it has been merged
tl;Dr today or tomorrow firmware selector will bring you same image as I was providing via GitHub actions.
EDIT:
Only one part is not merged - patches proposed by @rmandrad from Mediatek Feed. Soon I will make a Github action that will provide such image.
5 Likes
No, i use your build from sysupgrade file.
Thanks for ur reply. Do u mean that all mentioned changes merged on original openwrt:main or to ur fork? I used to build image via legacy method not conatiner builder or github actions.
you can use the firmware selector and it will bring you to the same point as we are now.
Just openssl dev crypto change from @rmandrad is not merged, but all others are.
1 Like
Thank you and @rmandrad for your hard work. There's been amazing progress in such a short timespan since BE14 started shipping.
1 Like
Hi @rmandrad ,thank you for all your work on commits for BPI-R4.
After commit 11be support #7302 the LUCI Status > Channel Analysis Radio 2 (6GHz) window does not display the bandwidth graphic for any 11be modes.
The problem is with file ~/openwrt/build_dir/target-aarch64_cortex-a53_musl/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js, because it has no knowledge of EHT bandwidth.
line 233
chan_width_text = local_wifi.htmode.replace(/(V)*H[TE]/,''), /* Handle HT VHT HE */
Suggested change to fix
chan_width_text = local_wifi.htmode.replace(/(V|E)*H[TE]/,''), /* Handle HT EHT VHT HE */
hoping you are able to investigate and make another commit to fix this small problem.
1 Like
let me have a look this piece of code has quite a lot missing like the eht/ht bands etc ..
btw... i spent some time looking at the code and it needs a massive change to show the hwmode ... the piece of code you changed only applies for the local interfaces and the iwinfo scan doesn't provide a straight answer on which hwmode the radio (that are non-local) is operating on
Thank you for investigating the other issues.
I was also looking at a method to centre the "Local Interface" name over the bandwidth graphic but I think this is beyond my programming ability.
I was trying to track down the implementation of the Wireless Offload patch. Do we know if it's going to be in mainline or included in any of your builds? @danpawlik @rmandrad
I guess my question is if they cherry-pick from the Mediatek feeds or they just include the entire feed?
all development into mainline and up streaming to linux wireless is led by @nbd ... also any refactoring of the 5.4 kernel patches will need to be submitted to upstream (not openwrt but linux wireless).
In fact, I am curious (and suspicious based on my qcom experience) why all that 5.4 work hasn't yet end up upstream.
1 Like
Ah okay, that makes a lot of sense. I noticed that all of their patches are designed around OpenWRT version 21.02 but I never considered all the refactoring that would be required to bring it to the newer kernels. Thank you for the clarification!
Is the decision on the part of Mediatek to design around kernel version 5.4 a "if it ain't broke, don't fix it" type of mentality? I feel like there would be some level of realized monetary gain to writing code for the newest kernels.
is all the code affinity they developed to optimise it (offloading, nat etc ) vs linux that goes much faster (the power of opensource) vs a "few" people that need to be on the payroll of a company ... and of course yes ensure there are features unique in the market . Still making my mind of qcom vs mediatek saying all this must say the banana rpi4 is a great device and well done to SINOVOIP in spite of a few shortcomings which are normal at this stage
2 Likes
Excellent insight and good conversation. Thanks!
Did you actually look at the sources and verify any of that?
Source (4) is a generic guide to sysupgrade, it has nothing to do with WED/WO, doesn't even mention it.
Regarding the definitions:
WED: The term stems from the original implementation which is part of MT7622 and offloads forwarding from Ethernet to Wireless, ie. WiFi TX is offloaded only. Hence packets received on Ethernet are dispatched to Wireless, hence the name. More recent versions (MT7986, MT7981 and later SoC) do support also taking care of the traffic received on the Wireless interface.
WO: Wireless Offload Firmware In order to perform WED on recent SoCs a dedicated offloading firmware is required. It is called WO firmware.
So to be clear: WED means offloading traffic forwarding from/to Wireless. It works with the existing flow-offloading aka. HWNAT engine of MediaTek SoCs, just like for forwarding Ethernet traffic. Newer SoCs need firmware to perform WED, and that is called WO firmware. Because WED is now bidirectional, MediaTek started to use the more generic term WO instead of WED, which suggests a unidirectional nature as it has been the case on MT7622. Today, the two terms (WED and WO) mean the same feature.
Please forget all the well-sounding but rather meaningless stuff that chatbot has told you. Thank you for at least having clearly marked that post to be the result of a Copilot chat.
6 Likes
Discovering APs by scanning is rather exhausting on the 6 GHz band because there are so many channels. Hence scanning by probe requests and listing to beacons on each and every possible channel is discouraged in the 6 GHz band and the spec suggests to use MBO (Multi-Band-Operation) and stapling the information about the AP on 6 GHz to the 5 GHz beacons. That's what you are seeing there.
3 Likes
There's some recurring issue I have with rmandrad's branch, and now with upstream:
Sometimes a connection between my laptop (intel be200) and AP is established, but only direct traffic works. Ie. I can connect to my AP from my laptop, but not to anything else on the network. In Wireshark can see broadcast and multicast traffic flowing towards my laptop, but seems like AP is deaf to DHCP requests originating from a laptop (so it can't propagate them further down the network and similarly with ARP traffic). Setting "broadcast to unicast" doesn't help. Wired clients connected to BPI-R4 have no issues, nor I have any issues connecting to any other APs (mt7915) with the same wireless config (but somewhat older OpenWRT snapshot). I have no acceleration enabled (no WED/WO nor hardware NAT offloading). The issue is sort of random, sometimes device enters such a state and for a couple of hours it doesn't work, and sometimes it goes back to working for a couple of hours (when I started writing this post, it didn't work, but now it does, so I can't debug it further). Happens across the bands (2G, 5G, 6G). I have a VLAN setup, so AP is bound to a br-lan.1 interface. No WDS enabled. Anyone perhaps experiences a similar issue?
Well what kind of animal would pass off something they asked a chatbot as something they know intimately, without listing sources? 
Thank you for providing clarification on the matter, as I noticed a couple of the references seemed irrelevant but didn't dig too far into it. My apologies if that quick search led anyone down the wrong path! (@danpawlik)