Belkin RT3200/Linksys E8450 WiFi AX discussion

diogenes · September 26, 2023, 9:25pm

I just got one of these devices again and flashed it with a build I made from the latest master. I am running into an issue where my wired clients cannot communicate with my wireless clients that are on the same subnet. Some notes:

This was reproducible both with WED & offloading all enabled, as well as with them all disabled
My build did not include the 'bridger' package
Wireless clients can communicate with other wireless clients on the same subnet
Wired clients can communicate with other wired clients on the same subnet
Both Wired & Wireless clients can access the internet without issues
I have used virtually identical configurations on other OpenWRT devices (built from master) such as a Redmi AX6000 and a DL-WRX36 and I do not run into this issue. It seems to be isolated to this device

Does/has anyone else observed similar things? And if so, were you able to resolve it?

eginnc · September 27, 2023, 12:52am

Ive been running OpenWrt SNAPSHOT r23880-8554a4a7e3 for 22 days on an RT3200 set up as a dumb AP with my NAS connected to one of its ports. No issues with wireless clients on that AP communicating with the wired NAS. Doesn't help you with the latest snapshot you are using, but perhaps it at least helps narrow down when it happened if it's confirmed by others.

diogenes · September 27, 2023, 3:10am

Heh, just for kicks I switched to 23.05.0-rc3 r23389-5deed175a5 and also added the bridger package but the issue is still present. My memory is starting to come back to me on why I stopped using this device haha. I think this issue was introduced quite a while ago like not too long after the initial release of 22.03.

I don't think my network configs are anything too crazy, but I do have a VLAN I guess that could be messing with things.

Here's my network config:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd47:6696:92df::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	option ipv6 '0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	list dns '192.168.1.1'
	option delegate '0'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option peerdns '0'
	list dns '45.90.28.115'
	list dns '45.90.30.115'
	option delegate '0'

config device
	option type '8021q'
	option ifname 'lan1'
	option vid '3'
	option name 'lan1.3'
	option ipv6 '0'

config device
	option name 'eth0'
	option ipv6 '0'

config device
	option name 'lan2'
	option ipv6 '0'

config device
	option name 'lan1'
	option ipv6 '0'

config device
	option name 'lan3'
	option ipv6 '0'

config device
	option name 'lan4'
	option ipv6 '0'

config device
	option name 'wan'
	option ipv6 '0'

config device
	option type 'bridge'
	option name 'br-iotlan'
	list ports 'lan1.3'
	list ports 'lan3'
	list ports 'lan4'
	option ipv6 '0'

config interface 'iotlan'
	option proto 'static'
	option device 'br-iotlan'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	list dns '192.168.2.1'
	option delegate '0'

Here's my wireless:

config wifi-device 'radio0'
	option type 'mac80211'
	option phy 'wl0'
	option cell_density '0'
	option htmode 'HT20'
	option band '2g'
	option channel '11'
	option country 'US'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'iotlan'
	option mode 'ap'
	option ssid 'BF-IoT'
	option encryption 'sae-mixed'
	option disassoc_low_ack '0'
	option key 'xxxxx'

config wifi-device 'radio1'
	option type 'mac80211'
	option phy 'wl1'
	option cell_density '0'
	option htmode 'HE160'
	option band '5g'
	option channel 'auto'
	option channels '36 100'
	option country 'US'
	option he_su_beamformee '1'
	option he_bss_color '57'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'Bifrost'
	option encryption 'sae-mixed'
	option disassoc_low_ack '0'
	option key 'xxxxx'

config wifi-iface 'wifinet2'
	option device 'radio1'
	option mode 'ap'
	option ssid 'BF-IoT-5GHz'
	option encryption 'sae-mixed'
	option disassoc_low_ack '0'
	option key 'xxxxx'
	option network 'iotlan'

umayer · September 27, 2023, 7:07am

Adrian,
maybe you can help me understand the build process a little better.
I assume I would only get the latest mt76 if I build my own image, correct?
It would not yet be part of daily snapshots?
When I build my own image I follow these steps:

git pull
make distclean
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
make

Would that include the latest mt76?

And I guess you did not test your setup with a 5.15 kernel, correct?

Anteus · September 27, 2023, 8:20am

The mt76 version is set in package/kernel/mt76/Makefile so building with no changes gets you the same as snapshot but as the buildbots can take a while to build you can try it out directly by building yourself.

To try a newer version than snapshot you can change the PKG_SOURCE_VERSION to a newer commit hash in the mt76 repo.

For example latest mt76 now:
https://github.com/openwrt/mt76/commit/fcc2f3d82bc9d4d0a8f00d14e892055847c840a7

Change mt76/Makefile to
PKG_SOURCE_VERSION:=fcc2f3d82bc9d4d0a8f00d14e892055847c840a7

Gix · September 27, 2023, 10:54am

Yes, Anteus is right, but to be correct you must also edit the previous line from Makefile PKG_SOURCE_DATE with the correct date and the next line, PKG_MIRROR_HASH:=SKIP, then download the package with make package/kernel/mt76/download, you'll find the new mt76...tar.xz file in openwrt/dl and you can calculate the SHA-256 checksum and edit again Makefile with the correct PKG_MIRROR_HASH value. This way the package is downloaded only once.
My operations after make menuconfig are:
make download (download all needed packages for multi-core compiling)
make toolchain/install (make them first separately because it doesn't work in multi-core mode)
make -j9 (I have 8 cores)
I used the 6.1 kernel since it was available and didn't come back, and also gcc 13

diogenes · September 27, 2023, 4:17pm

Just in case anyone runs into the weird issue I was observing, just look here:

I was apparently just doing it wrong and it didn't really have anything to do with the device.

eginnc · September 28, 2023, 12:00am

Glad you got it sorted out. I should have mentioned I have several vlans set up on my RT3200 too, but moot point now.

zsolto1 · September 29, 2023, 7:06pm

Update: I switched back to 80 MHz channel width and now it looks like I got my bandwidth back on 802.11ax with wed enabled.

umayer · September 30, 2023, 1:37pm

I've built an image based on kernel 6.1 and with mt76 off of
fcc2f3d82bc9d4d0a8f00d14e892055847c840a7
I've enabled wed

cat /sys/module/mt7915e/parameters/wed_enable
Y

however, I don't see any values in
cat /sys/kernel/debug/ppe0/bind
even when running iperf3 via this AP.

Am I missing something?
I had SW offloading turned on and tried with both HW offloading on and off.

EDIT:
let me double check whether bridger is installed.

it is not... and according to

I need the LLVM tool chain

I followed the steps in

and I think I now have a working setup with WED:

# cat /sys/kernel/debug/ppe0/bind 
0028c BND IPv4 5T orig=213.20.175.56:4500->192.168.1.108:41971 new=213.20.175.56:4500->192.168.1.108:41971 eth=e8:xx:xx:xx:xx:c6->c8:xx:xx:xx:xx:b7 etype=0008 vlan=0,64 ib1=61402efa ib2=007e0460 packets=3125 bytes=676074

with 192.168.1.108 being my mobile phone.

_FailSafe · October 7, 2023, 1:31pm

Two questions for you, if I may...

Is WED consistently working for you on your build or does it seem to stop showing offloaded flows after some amount of uptime? My reason for asking is that @nbd had indicated there may be some WED regression and I've not heard any update around that. See here: https://github.com/openwrt/mt76/issues/754#issuecomment-1703703105
Are you seeing erratic connectivity on your RT3200 with the 6.1 kernel? I have tried twice to switch over to kernel 6.1 builds and each time (several weeks apart) I would see extremely consistent and unusable latency spikes on the ethernet side of the device. So much so that it makes it inoperable as an AP and it takes a long time to get a new image uploaded to it in order to flash back to a kernel 5.15 build.

I'm tempted to just test it again and see if the ethernet latency is back to normal with kernel 6.1. But if you can save me some time, I'm all for that too Thanks!

Update:
I just tried my kernel 6.1 build again (actually did a full make dirclean first) and my resulting image produces this type of behavior:

From the AP where I flashed my kernel 6.1 build --> 192.168.XX.5 being my gateway device:

root@AP-Office:~# ping 192.168.XX.5
PING 192.168.XX.5 (192.168.XX.5): 56 data bytes
64 bytes from 192.168.XX.5: seq=0 ttl=64 time=2058.193 ms
64 bytes from 192.168.XX.5: seq=1 ttl=64 time=1058.342 ms
64 bytes from 192.168.XX.5: seq=2 ttl=64 time=59.063 ms
64 bytes from 192.168.XX.5: seq=3 ttl=64 time=162.308 ms
64 bytes from 192.168.XX.5: seq=4 ttl=64 time=1457.042 ms
64 bytes from 192.168.XX.5: seq=5 ttl=64 time=458.088 ms
64 bytes from 192.168.XX.5: seq=6 ttl=64 time=3946.141 ms
64 bytes from 192.168.XX.5: seq=7 ttl=64 time=2946.792 ms
64 bytes from 192.168.XX.5: seq=8 ttl=64 time=1950.370 ms
64 bytes from 192.168.XX.5: seq=10 ttl=64 time=4960.722 ms
64 bytes from 192.168.XX.5: seq=11 ttl=64 time=3961.502 ms
64 bytes from 192.168.XX.5: seq=12 ttl=64 time=2961.972 ms
64 bytes from 192.168.XX.5: seq=13 ttl=64 time=1962.462 ms
64 bytes from 192.168.XX.5: seq=14 ttl=64 time=962.632 ms
64 bytes from 192.168.XX.5: seq=15 ttl=64 time=0.514 ms
64 bytes from 192.168.XX.5: seq=16 ttl=64 time=1527.167 ms
64 bytes from 192.168.XX.5: seq=17 ttl=64 time=527.417 ms
64 bytes from 192.168.XX.5: seq=18 ttl=64 time=1053.480 ms
64 bytes from 192.168.XX.5: seq=19 ttl=64 time=53.528 ms
64 bytes from 192.168.XX.5: seq=20 ttl=64 time=0.535 ms
64 bytes from 192.168.XX.5: seq=21 ttl=64 time=63.599 ms
64 bytes from 192.168.XX.5: seq=22 ttl=64 time=404.229 ms
64 bytes from 192.168.XX.5: seq=23 ttl=64 time=0.381 ms
64 bytes from 192.168.XX.5: seq=24 ttl=64 time=107.587 ms
64 bytes from 192.168.XX.5: seq=25 ttl=64 time=4163.145 ms
64 bytes from 192.168.XX.5: seq=26 ttl=64 time=3163.613 ms
64 bytes from 192.168.XX.5: seq=27 ttl=64 time=2165.128 ms
64 bytes from 192.168.XX.5: seq=28 ttl=64 time=1165.411 ms
64 bytes from 192.168.XX.5: seq=29 ttl=64 time=165.575 ms
64 bytes from 192.168.XX.5: seq=30 ttl=64 time=0.479 ms
64 bytes from 192.168.XX.5: seq=31 ttl=64 time=0.486 ms
64 bytes from 192.168.XX.5: seq=32 ttl=64 time=1981.880 ms
64 bytes from 192.168.XX.5: seq=33 ttl=64 time=982.201 ms
64 bytes from 192.168.XX.5: seq=34 ttl=64 time=0.500 ms
64 bytes from 192.168.XX.5: seq=35 ttl=64 time=55.053 ms
64 bytes from 192.168.XX.5: seq=36 ttl=64 time=54.708 ms
64 bytes from 192.168.XX.5: seq=37 ttl=64 time=129.539 ms
64 bytes from 192.168.XX.5: seq=38 ttl=64 time=672.157 ms
64 bytes from 192.168.XX.5: seq=39 ttl=64 time=270.285 ms
...

umayer · October 8, 2023, 12:30pm

Hey Mark,
on 1:
Already when I tested WED with iperf3 I observed that a second manual invocation back to back did not use WED. Only later (after some time with no traffic?) WED was engaged again on iperf3.
I don't understand WED good enough to tell, but it made me think that some resource is blocked and only later once that resource is released a new WED could engage.
I still kept left WED active at that time.

However, I did observe issues with streaming apps on my TV later that day.
A day later a video conference had issues: Network connection dropped a couple of times for about 10 seconds.
Since then WED is disabled again.
Besides the odd behavior I also saw some of these error messages:
Mon Oct 2 07:52:53 2023 daemon.err hostapd: nl80211: kernel reports: key addition failed

on 2:
I did not observe any latency issues so far. Note that I did not only enable kernel 6.1 but also use a different version of mt76 (fcc2f3d82bc9d4d0a8f00d14e892055847c840a7).
So far it seems rock solid, but I think it is too early for a final verdict.
I did not see key addition failed messages anymore.

Right now I am happy with my image.
On kernel 5.15 I had STAs which showed WiFi connected but were not able to connect (e.g. ping to AP).
I then rebooted said device and all was good again. This happened in particular with many wireless devices. (i.e. It felt reasonably solid if only few persons were at home, but with visitors it happened more frequently)

My setup has VLANs and DAWN (802.11 k, r, v) as well as beamforming active on the APs and the router.
So far only WPA2, but will give WPA3 mixed mode a try soon (guest WiFi has opportunistic encryption enabled, i.e. 802.11w is already used)

andreagdipaolo · October 8, 2023, 12:59pm

Keep in mind that WPA3 (even mixed) and fast roaming don't play nicely with some Apple devices.
They will refuse to connect.

_FailSafe · October 8, 2023, 1:02pm

In my experience this is true, though I've only had it happen on truly old Apple devices (think iPhone 5 & 6). Here's the official Apple doc to indicate WPA3 support:

_FailSafe · October 8, 2023, 1:15pm

I may be able to dedicate some time today to trying my 6.1 build again and figure out what is causing me issues.

FWIW, I am running a very similar sounding configuration, including multiple VLANS+SSIDs, though I'm using Usteer instead of DAWN. On my primary and guest SSIDs, I have switched completely over to WPA3 only as I had some issues with WPA2/WPA3 mixed. In my household of ~20 Apple devices (all newer than iPhone 6 at this point) I have zero WPA3 issues.

My IoT SSID has another ~15 Android/Linux type devices, so for now I have had to leave it at WPA2 until device manufacturers start putting out better firmware updates for WPA3 support. Even WPA2/WPA3 mixed did not make some of these devices happy

andreagdipaolo · October 8, 2023, 1:18pm

I've had problems even with devices running the latest iOS. There are some threads here about this issue.

umayer · October 8, 2023, 2:20pm

@_FailSafe do you have 802.11r (fast transition) active?

odrt · October 8, 2023, 2:28pm

Pure WPA3 is perfectly fine. WPA3-WPA2 mixed mode is often causing problems.

github.com/openwrt/openwrt

FS#3108 - Some devices unable to connect in sae-mixed mode (WPA3/WPA2 Personal)

opened 05:01PM - 18 May 20 UTC

openwrt-bot

flyspray

*Freddicus:* Device: Netgear Nighthawk X4S (R7800) Software version: OpenWrt 1…9.07.2 r10947-65030d81f3 / LuCI openwrt-19.07 branch git-20.134.55291-ba0fb08 Steps to reproduce: - Start with the firmware linked here: https://openwrt.org/toh/netgear/r7800 - Remove wpad-basic - Install wpad-openssl - Configure network to broadcast in WPA3/WPA2 Personal (sae-mixed) Devices previously able to connect to WPA2 mode: - 2012 Macbook Pro on macOS Catalina 10.15.4 - Up-to-date raspberry pi 4 on raspbian buster If I switch the radio to WPA2 Personal only (wpa-psk if not using luci, I believe), they can connect. I switch it back to WPA3/WPA2 Personal (sae-mixed) they cannot connect. Let me know what logs to gather and how to gather them. If it's a client issue, please confirm, but my understanding is that mixed mode should support all WPA2 Personal compatible devices.

This can be avoided with an AP with virtual AP capability: create two SSIDs, one for pure WPA2
for older only WPA2 compatible devices and another with pure WPA3 for recent devices. Avoid WPA3-WPA2 mixed mode.

The Belkin RT3200 aka Linksys E8450 has vap multi SSID support.

Or configure the 2.4 GHz interface to WPA2 and let all WPA3 incompatible stations connect to this SSID.

andreagdipaolo · October 8, 2023, 3:01pm

My current setup is: guest (2.4+5 same name) and my main one (2.4+5 different names), with the exception of a IoT ntework on the 2.4 GHz.
I wanted WPA2/3 or 3 only on all SSIDs but at the moment I chose this configuration:
Fast roaming enabled only on guest and main, on IoT not enabled because it's only coming from a single AP. Guest on WPA2, main on WPA3, IoT on mixed.
I'm quite happy with that.

_FailSafe · October 8, 2023, 5:07pm

Indeed, I do