Belkin RT3200/Linksys E8450 WiFi AX discussion

For Developers
1958

Just thought I would update this thread that I have updated to SNAPSHOT r19372-d6a3949922 and have improved but still not-fully-working hardware offload support it seems.

With hardware offloading enabled, I am able to load web pages from my laptop connected wirelessly but amazon alexa won't control my philips hue hub which would be my test that everything was working like it did with firewall 3.

Hope this helps with testing and others looking to get hardware flow offloading fully working.

Thanks again to everyone's efforts in making this an amazing router!

1959

Looking at latest commits, it seems that "wed" code is included now in the master branch of the mt76 driver, so the next openwrt master snapshot will have the full hw acceleration code included. However, the wed_enable parameter of the mt7915e module is set to false by default in code. I don't know if editing the /etc/modules.d/mt7915e file with "mt7915e wed_enable=Y" will work, maybe someone has a better idea (of course instead of changing the source code). Also the PPPoE issue should be addressed (https://github.com/openwrt/openwrt/issues/9531) in order for hw offloading to work for these types of connections.

4 Likes
1960

Yes, it's working :slight_smile: I tested the reverse, i.e. compiled with wed_enable = true then set "mt7915e wed_enable=N" in the /etc/modules.d/mt7915e file, reboot and there are no more entries when doing cat /sys/kernel/debug/mtk_ppe/bind. Also the file /sys/module/mt7915e/parameters/wed_enable contains a N (it seems this is N always). And of course much more CPU usage during downloads by WLAN.

2 Likes
1961

Cool, so if I am understanding this correctly, Hopefully everything works as expected after updating to the next SNAPSHOT and leaving the settings as is (i.e. WED disabled)?

The things working as expected would be a couple of cloud IP cameras connecting with PoE and Alexa Hue lights control connecting with the hub on Ethernet and the Echo on WiFi.

Of course, my connection is PPPoE (I wish my ISP CenturyLink would modernize the way customers connect to their service - the fiber infrastructure is great but not a fan of PPPoE and the 6 to 4 IPv6 functionality they are using).

1962

My tests and observations are not related to your issues. I've only tested how can the wed acceleration be enabled in order to have a fully hardware offloaded path usable with high-speed wireless clients. And the conclusion is that we only need a patch for PPPoE connections and the wed_enable parameter set to true. I did not test with fw4, only with the legacy firewall.
L.E.: I've tested with an ethernet cable - the CPU usage during data transfers is definitely higher than WLAN, don't know if this is normal. The transfer speed was roughly the same.
CPU3

1 Like
1963

Copy that. It is most helpful nonetheless, thanks!

1964

From my understanding, it's about lan->wifi offload. Wed now only supports wan->wifi.

1965

hello, i'm using 2x rt3200 with r19372-d6a3949922 and HE160 on channel 36 and 100
both ap's having a bad upload rate when i'm some meters (3-4) away
i also notice that my samsung galaxy s22+ is switching often to the one on channel 36 although the channel 100 one has way better signal

are there some patches or fixes i need to apply to get the full experience?

1966

I don't think anyone's had a good experience yet with HE160 based on feedback it looks like. I don't think the chipset "officially" supports it, or if it does officially, the performance tends to be slower than 80.

1967

Output power varies depending on the country code set and also radio hardware. Here with ETSI (PT) country code:

			* 5180 MHz [36] (23.0 dBm)
			* 5200 MHz [40] (23.0 dBm)
			* 5220 MHz [44] (23.0 dBm)
			* 5240 MHz [48] (23.0 dBm)
			* 5260 MHz [52] (20.0 dBm) (radar detection)
			* 5280 MHz [56] (20.0 dBm) (radar detection)
			* 5300 MHz [60] (20.0 dBm) (radar detection)
			* 5320 MHz [64] (20.0 dBm) (radar detection)
			* 5500 MHz [100] (26.0 dBm) (radar detection)
			* 5520 MHz [104] (26.0 dBm) (radar detection)
			* 5540 MHz [108] (26.0 dBm) (radar detection)
			* 5560 MHz [112] (26.0 dBm) (radar detection)
			* 5580 MHz [116] (26.0 dBm) (radar detection)
			* 5600 MHz [120] (26.0 dBm) (radar detection)
			* 5620 MHz [124] (26.0 dBm) (radar detection)
			* 5640 MHz [128] (26.0 dBm) (radar detection)
			* 5660 MHz [132] (26.0 dBm) (radar detection)
			* 5680 MHz [136] (26.0 dBm) (radar detection)
			* 5700 MHz [140] (26.0 dBm) (radar detection)
			* 5720 MHz [144] (13.0 dBm) (radar detection)
			* 5745 MHz [149] (13.0 dBm)
			* 5765 MHz [153] (13.0 dBm)
			* 5785 MHz [157] (13.0 dBm)
			* 5805 MHz [161] (13.0 dBm)
			* 5825 MHz [165] (13.0 dBm)
			* 5845 MHz [169] (13.0 dBm)
			* 5865 MHz [173] (13.0 dBm)

So only channel 100...140 have full power (here for me, it may well be different for you if you are located in a different regulatory domain)

1 Like
1968

MediaTek does advertise the MT7915 to be capable of HE160 rates, but only 2T2R. Belkin/Linksys, however, doesn't advertise this device to be capable of HE160, so it can be that other components in the RF path don't work well for that.

2 Likes
1969

@daniel - What is the command to generate that output?

1970

Looks like iw phy output to me. Additionally, you may also try iw reg get to take a look at your set region's limits.

If you choose 160mhz width and it crosses the boundaries of these limits, it'll pick the lower one of course.

Eg.

        (2400 - 2483 @ 40), (N/A, 36), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
        (5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
        (5730 - 5850 @ 80), (N/A, 36), (N/A)

This ends up as 20dBm + DFS for me, as it crosses into that region. (Obviously the hardware isn't going to go up to 36dBm/4W output power on channel 149, which is why you look at iw phy)

Additionally, your region may not have the adjacent spectrum available for many/any 160mhz anyway. In my example above, there's only one 160 channel available, at 36.

Sure you can push 1.6gbit/s over 160mhz on iperf next to the unit (Well, ~930mbit realistically because gigabit ports. I don't know how well port bonding/aggregation would work.), but it may be fairly detrimental for your coverage depending where you live.

2 Likes
1971

Yes, that works, thank you.

That is interesting... for my country code (US), the values are in fact different:

			* 5180 MHz [36] (23.0 dBm)
			* 5200 MHz [40] (23.0 dBm)
			* 5220 MHz [44] (23.0 dBm)
			* 5240 MHz [48] (23.0 dBm)
			* 5260 MHz [52] (24.0 dBm) (radar detection)
			* 5280 MHz [56] (24.0 dBm) (radar detection)
			* 5300 MHz [60] (24.0 dBm) (radar detection)
			* 5320 MHz [64] (24.0 dBm) (radar detection)
			* 5500 MHz [100] (24.0 dBm) (radar detection)
			* 5520 MHz [104] (24.0 dBm) (radar detection)
			* 5540 MHz [108] (24.0 dBm) (radar detection)
			* 5560 MHz [112] (24.0 dBm) (radar detection)
			* 5580 MHz [116] (24.0 dBm) (radar detection)
			* 5600 MHz [120] (24.0 dBm) (radar detection)
			* 5620 MHz [124] (24.0 dBm) (radar detection)
			* 5640 MHz [128] (24.0 dBm) (radar detection)
			* 5660 MHz [132] (24.0 dBm) (radar detection)
			* 5680 MHz [136] (24.0 dBm) (radar detection)
			* 5700 MHz [140] (24.0 dBm) (radar detection)
			* 5720 MHz [144] (24.0 dBm) (radar detection)
			* 5745 MHz [149] (27.0 dBm)
			* 5765 MHz [153] (27.0 dBm)
			* 5785 MHz [157] (27.0 dBm)
			* 5805 MHz [161] (27.0 dBm)
			* 5825 MHz [165] (27.0 dBm)
			* 5845 MHz [169] (27.0 dBm) (no IR)
			* 5865 MHz [173] (27.0 dBm) (no IR)

So for mine, channels 100-144 are 2.0 dBm lower but channels 149-173 are 1.0 dBm higher. Odd.

1972

That's not odd, that's regulations :wink:

1973

i set my regulations to "forbidden here, ask me" there are no dfs and high power :smiley:

edit:
has anyone a working roaming setup with wifi 6 and wpa3?
looks like 802.11r is not working with 802.11w which is needed for wp3
and without 802.11r my smartphone stays on the ap with lower signal, even if i stand right before the other ap

1974

Is there a setting that involves no power throttling for testing in a faraday cage or on the moon? What is the effect of no country code being set? Driver default. But what does that mean in practice?

So legitimate question: what setting would one use for use on the moon?

1975

802.11r has not much to do with the roaming decision -- it just allows faster roaming by having the APs exchange key data so the client won't have to do full handshake again. And that generally works well with management frame protection enabled (802.11w).
If you want steered roaming (ie. not the client but the AP taking the decision to now move the client over to another AP) you need additional software. In OpenWrt we got usteer for that.

4 Likes
1976

I am getting about 930 Mbps using HE160 and about 600 MBps when using HE80. Yes HE160 works very well.

3 Likes
1977

I have a question for those more familiar with functionality across the different versions of OpenWrt and am hoping someone can help explain what I should expect.

I just tried updating to the latest .0.6.4 release to move over to the 22.03 SNAPSHOTs and found the new version to be quite different from the current SNAPSHOTs.

The main differences being auc and attended sys upgrade were missing.

Also when I restored settings I couldn't see where my other router was connecting with the mesh node I had setup (although I didn't look into this since I wanted to keep auc and attended sys upgrade for the time being and have reverted back to the 22.xx SNAPSHOTs).

I am aware that I could use the image builder page (or figure out how to build my own images) to keep up-to-date but I would rather do this with auc.

Is it just a matter of adding those packages to a 22.03 SNAPSHOT? If they are omitted entirely for the time being, do you think those will be part of the release when it's finalized?

Hoping someone in the know can advise.