Wireless signal inferior to stock firmware (Cudy WR3000H)

Installing and Using OpenWrt Network and Wireless Configuration
1

Just wanted to put a warning out there for those thinking of buying this router, but any suggestion to fix this is welcome of course.

The WR3000H V1.0 marketed as supporting Wi-Fi 6 - Beamforming - UL/DL OFDMA - MU-MIMO, consistently gets better quality signal with stock firmware compared to OpenWrt, here's a quick before & after comparison, tested using the 2.4 GHz frequency in 3 different points of a house on Android using the app com.vrem.analyzer:

Cudy 2.2.7-20240906-085755
POINT A = -53dBm
POINT B = -61dBm
POINT C = -72dBm

OpenWrt 24.10.2
POINT A = -58dBm
POINT B = -70dBm
POINT C = -78dBm
1 Like
2

I suspect this comes down to you not configuring it with the same features. Having said that, ideally all features should work at least as good as stock.

If you implemented an optimal configuration and it still works worse, that's a bug relative to project goals.

1 Like
3

Did you set wifi country code?

2 Likes
4

Can you do this on OpenWrt firmware?

cat /dev/mtd2 > /tmp/factory
hexdump -C /tmp/factory

then check the value of 0x19a

5

I've tried to mimic the "Operating frequency" of the stock firmware (ax/k/v, 20MHz, same Channel) according to what the Android app reported on the surface, but it didn't help.

I've also played around with many of the other settings exposed by the LuCI GUI such as the country code (tried both my country and "00 - World") WMM Mode, checking if the Maximum transmit power was set to the max, but nothing seemed to help.

At some point I've even tried to add random lines found from the internet to "/etc/config/wireless" that seemed vaguely related to Wi-Fi signal such as these:

config wifi-device 'radio0'
[...]
	option he_su_beamformer '1'
	option he_su_beamformee '1'
	option he_mu_beamformer '1'
	option he_bss_color '8'
	option eht_su_beamformer '1'
	option eht_su_beamformee '1'
	option eht_mu_beamformer '1'
	option he_spr_srg_bss_colors '1 2 10 63'
	option he_twt_responder '1'
	option su_beamformer '1'
	option su_beamformee '1'
	option mu_beamformer '1'
	option mu_beamformee '1'
	option he_ulofdma '1'
	option he_dlofdma '1'
	option noscan '1'
	option bursting '1'
	option ff '1'
	option compression '1'
	option xr '1'
	option ar '1'

...to no avail.

It's 0x00. Full line:
00000190 12 5b 48 4c 00 28 00 00 0f d0 00 00 00 00 00 00 |.[HL.(..........|

6

I've done some past research into the mt76 driver and its source code, so I hope some of this information will be helpful. If you could let us know what WiFi version your Android device supports, that would also help.

A lot of the parameters that you've added to your wireless config have no effect on range/signal strength. Others just do nothing and are ignored. In the mt76 wireless driver, newer WiFi 6 features like OFDMA and UL/DL MU-MIMO are primarily handled on a driver level when it communicates with the MCU. They are not directly enabled by configuration settings in your wireless interface or hostapd. The mt76 driver will automatically enable OFDMA and MU-MIMO if he_mu_beamformer is enabled and the WiFi interface is in HE or VHT mode (DL MU-MIMO only for VHT). If you'd like to verify that it's working in a terminal, on phy0 or phy1 you can first do echo 1 > /sys/kernel/debug/ieee80211/phy*/mt76/muru_debug (MediaTek calls it MURU). After that, you can view OFDMA stats with cat /sys/kernel/debug/ieee80211/phy*/mt76/muru_stats. The parameters in your config for TWT and BSS coloring have no impact on range. They are WiFi 6 features to improve battery life and reduce interference, respectively. There is no reason to specify them in your config because hostapd will enable TWT by default if the driver advertises it, and it will generate a random integer automatically for BSS coloring. Your EHT settings are for WiFi 7, not WiFi 6. All that to say, a lot of the WiFi 6 features your router advertises are already enabled in OpenWrt, so you don't have to do anything.

As to what's actually causing your problem vs. stock firmware, it probably comes down to either beamforming or rate control. If you're using an older WiFi 4 client, you can enable implicit beamforming with echo 1 > /sys/kernel/debug/ieee80211/phy*/mt76/implicit_txbf and then disconnect and reconnect. That may provide a small range benefit. If it's a newer client, you can install MediaTek's proprietary beamforming from their OpenWrt 24.10 fork, but you'd have to compile it. I'm not saying that the explicit beamforming built into OpenWrt doesn't work, but it might be a little less effective than MediaTek's proprietary version. Also, check what channels are available and make sure you're using the highest TX power. Hope this helps.

7

I think this topic demonstrates that support for features of devices should probably be documented and measured, which would also drive sales of the more supported devices, which now requires someone to still consider many different options.

Having said that, it's probably kind of a thankless job, so the economics of it are unclear. I am just suggesting that having something like the Home Assistant quality scale would be welcome despite its flaws.

8

so all in all, did you revert back to stock and still got better results?