OpenWRT will try to use wireless-regdb to approximate settings - so that's what it knows to use...
wireless-regdb has no idea of what the radio is actually capable of...
I use woziwrt's build, regdb is patched. My Linksys complies with regdb so this cannot explain the huge discrepancy between the signal strength of these two routers.
Can't help you with a fork...
I appreciate you trying to help. Woziwrt patches regdb to open up txpower limits: [Moderator EDIT: URL removed]
Everything else is kept as close as possible to OpenWrt HEAD.
Just to reiterate - I do not think the TX power issue is software related, or at least, txpower settings - related. What I'm trying to say here is that the BE14's transmitter seems to be defective. It's TX power is anemic and much less than what it advertises, even with EEPROM/txpower patch applied and regdb effects ruled out.
On the flip side, it also sees much higher noise floor level so we're getting hosed in bot RX and TX scenarios.
That patch is plain insane and not worth discussing. Even ignoring any potentially valid reasons to extend the limits (e.g. the -3 dBm because of lacking tpc and other cautious reductions)- this simply ignores any kind of regulatory requirements and results in offensively non-compliant and plain illegal behaviour. Your only -questionable- hope would be that most consumer hardware physically won't quite approach the limits anyways (or at least exceeds it by not that much to be noticed from the outside, a dangerous game).
Really, if you want to see changes here, you need to convince linux-wireless and wireless-regdb upstream of your changes, and why they comply with the legally binding regulations for your region.
Hint: you 'just' have to provide a working and validated tpc implementation for your preferred wireless driver to double tx power...
Closing your eyes and pretending that laws don't exist or aren't enforced won't get you anywhere. 6-figure fines can be applied and enforced, as well as further hardware lockdowns in the future, which won't help anyone.
1 Like
so the announced 10GB is reaching stable max 6GB ? am i reading correctly ?
In the current state of software development, this is unfortunately the case. For a single TCP stream. On the other hand, it is possible to settle for relatively good performance for IPsec 
thx for all those information 
at least it gives a bite more time to my provider to connect me to fiber 
1 Like
I totally agree with what you wrote. The patch was created for testing purposes only and not for general use. I have decided to remove it from my GH in the next commit.
Does anyone know how to make the MTK feed reason when including MHI?
Building backport-include/backport/autoconf.h ... done.
CC [M] /home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.o
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c: In function 'trigger_edl_store':
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c:146:24: error: 'struct mhi_controller' has no member named 'edl_trigger'
146 | ret = mhi_cntrl->edl_trigger(mhi_cntrl);
| ^~
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c: In function 'mhi_init_mmio':
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c:544:15: error: implicit declaration of function 'mhi_get_channel_doorbell_offset' [-Werror=implicit-function-declaration]
544 | ret = mhi_get_channel_doorbell_offset(mhi_cntrl, &val);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c: In function 'mhi_register_controller':
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c:1043:22: error: 'struct mhi_controller' has no member named 'edl_trigger'
1043 | if (mhi_cntrl->edl_trigger) {
| ^~
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c: In function 'mhi_unregister_controller':
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c:1082:22: error: 'struct mhi_controller' has no member named 'edl_trigger'
1082 | if (mhi_cntrl->edl_trigger)
| ^~
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c: At top level:
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c:1470:18: error: initialization of 'int (*)(struct device *, struct device_driver *)' from incompatible pointer type 'int (*)(struct device *, const struct device_driver *)' [-Werror=incompatible-pointer-types]
1470 | .match = mhi_match,
| ^~~~~~~~~
/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.c:1470:18: note: (near initialization for 'mhi_bus_type.match')
cc1: all warnings being treated as errors
make[10]: *** [scripts/Makefile.build:243: /home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host/init.o] Error 1
make[9]: *** [scripts/Makefile.build:480: /home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi/host] Error 2
make[8]: *** [scripts/Makefile.build:480: /home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/drivers/bus/mhi] Error 2
make[7]: *** [Makefile:1921: /home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7] Error 2
make[6]: *** [Makefile.build:13: modules] Error 2
make[5]: *** [Makefile.real:105: modules] Error 2
make[4]: *** [Makefile:121: modules] Error 2
make[4]: Leaving directory '/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7'
make[3]: *** [Makefile:408: /home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mac80211-regular/backports-6.14-rc7/.built] Error 2
make[3]: Leaving directory '/home/edoardo/openwrt-builder/bpi-r4-mtk/openwrt/package/kernel/mac80211'
time: package/kernel/mac80211/regular/compile#2.09#0.38#2.42
ERROR: package/kernel/mac80211 failed to build (build variant: regular).
Not sure it would be considered "defactive" - more like this is a development board, and not a commercial product.
That, taken in to consideration, the BPI-R4 is early access to the MediaTek core chipsets, and of course, the radio...
Work here is not in vain, as once we see commercial hardware, most of the work shuold translate over...
you mean doing the work of the company instead? 
to be honest, that should be clearly mentioned on the product itself or as description which is far from the case.
i don't mind personally because i don't use the wifi and the board should do the expected work but honestly...the commercial approach is borderline when advertised as a full router with wifi7 and blablabla.
nothing against you in my reply ofc! 
i find it even more ballsy to create fork based on the R4 -> 2.5g, lite and so forth when the basic is not properly covered 
Do you guys experience same as me? I use @woziwrt latest image. When Macbook M3 pro connect to any of the SSID, Openwrt crash and restart. From log I don't see any useful info. Seems it suddenly reboot.
Rahzadan/openwrt_bpi-r4_mtk_builder: OpenWRT Builder for BPI-R4 with Mediatek Feeds
Updated my repo to use the latest commits from OpenWrt 24.10 and MTK Feeds. Added updated firmware binaries as well. I'll try to do this on a semi-weekly basis, unless a major patch / fix / update is posted by OpenWrt / MTK.
Well yesterday my router stopped working. I thought it was because of some packet update but as I've been testing...it's been getting worse...I've created another thread...but it looks like there's no solution and I'll have to get a warranty:
Repo updated & new release published.
3 Likes
@fatal1101 Are you referring to the duplicate port status entries? I inquired about this last month.
See here:
2 Likes
Thanks ..
Sorry to bother, can you update me what is the latest WiFi 7 320Mhz performance on bpi-r4?