Belkin RT3200/Linksys E8450 WiFi AX discussion

I recommend that you watch this video and not use Software flow offloading.

Buy a router or AP with MediaTek hardware, it is the closest thing to a true Open source.

@nbd is Felix Fietkau and he's the guy who did that presentation and developer of the mt76 driver.

6 Likes

nice video elan thanks

1 Like

I am using my Belkin RT3200 at 160mhz on the 5ghz channel. While this is working fine for my Laptop with an AX 160mhz WiFi chipset, it's giving me some issues with two AC 80mhz WiFi Android phones.

  1. Whenever my laptop is connected (just connected, no actual load), my phone only gets 100-200 Mbit instead of the 500 Mbit it pulls when my laptop is not connected.
  2. Regardless of whether my laptop is connected, the phones seem to strongly prefer the 2.4ghz band, switching even when the 5ghz connection still has good strength and never switching back to 5ghz, even when right next to the AP. This worked fine with my previous AC router.

Does anyone experience issues, and if so, did you get the AP and 80mhz AC phones to play nice with each other?

After reading your post I tried moving mine from 80 to 160 but the radio would not come up at all. What channel are you on? Can you post your /etc/config/wireless?

Please note that it takes a little over a minute for the channel to come up due to DFS scanning, so please be patient when you utilize a DFS channel (which I think is true by default for 160mhz channels due to how wide they are). Config below:

root@OpenWrt:~# cat /etc/config/wireless 

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/18000000.wmac'
	option band '2g'
	option htmode 'HT40'
	option channel 'auto'
	option country 'NL'
	option cell_density '0'
	option noscan '1'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'SSID'
	option encryption 'psk2'
	option key 'PasswordHere'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '5g'
	option htmode 'HE160'
	option channel 'auto'
	option country 'NL'
	option cell_density '0'
	option noscan '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'SSID'
	option encryption 'psk2'
	option key 'PasswordHere'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'

config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option ssid 'SSID Guests'
	option encryption 'psk2'
	option isolate '1'
	option key 'PasswordHere'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option network 'untrusted'

config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option ssid 'SSID Guests'
	option encryption 'psk2'
	option hidden '1'
	option isolate '1'
	option key 'PasswordHere'
	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option network 'untrusted'

Nice video to watch so thank you for sharing it. I not not understanding why the software flow offloading is a bad thing. Is it because it uses closed source blobs?

1 Like

I reset the channel to auto and found that it selected 100 and did actually come up. When I did some speed tests from my phone, I found 160 MHz was no faster than 80 MHz.

I don't think it's a fair comparison though because the tests at 20, 40, and 80 MHz were on channel 149 which uses a high value for transmit power (27 dBm) whereas channel 100 uses 23 dBm. I could not get 160 MHz to work on channel 149 or any other channel. Is this to be expected?

Does your phone even support 160mhz channel width? Not many phones do. You can check this on the Wireless page in Luci. It will list whether devices are connected with a 80mhz or 160mhz channel width. If you phone connects with 80mhz because it doesn't support 160mhz, not seeing an improvement is to be expected.

This is expected. It needs a block of 160mhz wide to be able to come up. There is only room for a 80mhz block, it won't be able to come up. This picture explains this pretty well:

Upon inspecting luci's associated stations, it does not. Good point :smiley: I cannot help to confirm your findings.

Yes, and I must point out that Felix said all that in 2015 (the RC3 2021 logo is just media.ccc.de channel logo, the video is more than 6 years old!) and the MediaTek Chipset he was working on at the time was MT76x2E. Now 6 years later, we actually do find plenty of devices with wireless chips which run very well with that driver and it's the best we have. I mean, we are all here in this thread because we are using a rather recent MediaTek-based device for which we are able to build really almost everything from (of course, open-)source, apart from DDR3 RAM calibration at boot and the very small mt76 uC firmware Felix mentions in that video (ok, it did get a little bit bigger over time, but still nothing compared to ath11k). And with that we manage to get close to a gigabit/s over the air.

No, generally there is nothing wrong with flow offloading imho. The talk is about a WiFi driver and mentions the hell of WiFi MAC offloading QCA introduced into their WiFi chipsets and the fact that you have to use all that to even use the hardware at all.
Hardware flow offloading doesn't require proprietary firmware, but just uses the hard-wired offloading functionality of the chip (the blueprint of the chip is, of course, proprietary, but that's true for all hardware we currently support). To the paranoid: I consider it extremely unlikely to find hardware backdoors there, because that kinda of backdoor would not be fixable in case it is discovered by the public, and if needed, there could also be hidden backdoors in the Ethernet controller or switch IC (and those you can't just turn off to be safe and still use the device). So even if some intelligence agency managed to corrupt developers to hide some bugs in there, that would just be the wrong place to do so and there are (unfortunately) much better places to do that.

I think what @elan wanted to point out is that even if hardware flow offloading may crash and forces you to use software flow offloading (or no offloading) instead, this is still so much better than QCA where you got those huge firmware blobs doing basically everything and our little open source Linux system just sits there to configure the hardware and provide the Web-UI.

7 Likes

You can partially though :slight_smile: My phone doesn't support 160mhz either, but the second issue I am experiencing is that the phone will prefer 2.4ghz over 5ghz. It will connect to 5ghz initially, but switch to 2.4ghz quite often, and remain connected the 2.4ghz, even when the signal strength for 5ghz is fine.

It could be that enabling 160mhz channel width is making devices connecting with 80mhz width less stable.

Yes, this observation is true. The higher the channel bandwidth, the less range at the same power. Simply because the same amount of energy is now spread over a larger amount of spectrum.
In case of MT7915E chip using 160Mhz channels also reduces RX diversity to 2 chains instead of 4 when using 80MHz (or less) channel bandwidth, so RX sensitivity is also lower when operating at 160MHz.

3 Likes

That makes sense. And a 160mhz AP cannot use the majority of the power for just the 80mhz part that is being used to communicate with a 80mhz client?

I know the downside of only being able to use 2 spatial streams when running in 160mhz mode with this device, but I don't have a single device that is able to use more than 2 spatial streams, so the downside of only being able to use 2 spatial streams is rather limited for me. Furthermore, enabling 160mhz gives a very nice speedup for my 160mhx AX device over just running 80mhz. It would be a shame if I had to disable 160mhz just for the sake of keeping 80mhz clients happy.

No, it can't do that, unfortunately.

You would still benefit from RX diversity (resulting in better sensitivity and hence more range) when using 4 RX chains intead of 2, even if the device connected it 1T1R.

3 Likes

I just bought my first Belkin RT3200, and was considering using it in mesh mode with Deco P9's running my own image. What sort of performance are you getting via the mesh? The Deco proprietary mesh was much faster than using 802.11s when I tried, so I am curious what your experience has been.

400 Mbit/s compared to 700 Mbit/s with WDS.

1 Like

Belkin

Hi all, a noob to the world of OpenWRT here. I got the Belkin RT3200, put the OpenWRT firmware on it and for the most part its working really well, except I cannot get the WIFI AX to work. Radio1 seems to be not "powered on" for lack of a better technical term (screenshot)
Or its on and enabled but the bitrate seems to be missing there. I have tried playing around with various settings, but I am not sure what I am doing wrong here.
Any suggestions? Thanks.

which version of openwrt you are installed on daniel files

please reupdate in the last snapshot because he seems you are again in initframs recovery mode ..

but not sure

It is the "regular" install not the initframs recovery image.

This is the name:
openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade
Thanks

Belkin2

1 Like

ok you has install with 0.6.1 ?