Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02

I am seeing some discussion and commits suggesting that WRT3200ACM/WRT32X and others may not be supported on 22.03.x releases any further due to that mvebu network switch bug where it’s acting as a hub.

It seems that it will be supported once again once stable builds with kernel 5.15 is released.

Does anyone know if we should go back to a previous release?

Or would it be a good time for the community to come together and create builds based on 5.15 trunk?

snapshots work presumably, plus there are community builds to be had.

1 Like

I may end up switching over to snapshots because I prefer a more vanilla/default experience and make my own changes from there.

Some people above had issues, others didn't. They'd have to follow-up with us to say if it was resolved? Are you talking about the issues people described in this thread in the last six months, or is this "mvebu network switch bug where it's acting as a hub" something newly reproduced? I did just notice that 22.03.3 wasn't built for the Linksys WRT devices.

Different, see thread

Community builds? Where can I find these?

this, there are images off the link on my avatar or github, not sure if hnyman still offers one.

1 Like

Master snapshot is running great on my WRT32X with kernel 5.15 for over 2 weeks. The switch and leds are fixed from my testing. I wouldn't go back to 22.03 or see any need for a new community build, just run Master. See my post here:

[Divested-WRT: No-nonsense hardened builds for Linksys WRT series - #942 by phinn]

Here are the packages I install via ssh right after a clean master snapshot install works great for me (lot of storage stuff since I run a 2TB SSD with Samba network shares for Kodi etc):

opkg update && opkg install luci luci-ssl irqbalance luci-app-advanced-reboot luci-app-sqm luci-app-simple-adblock luci-app-upnp luci-app-samba4 kmod-usb3 kmod-ata-marvell-sata kmod-usb-storage kmod-usb-storage-uas block-mount usbutils mount-utils luci-app-hd-idle kmod-fs-exfat nano nmon htop iperf3

1 Like

Thanks. Do the builds include Luci or must it be installed after flashing?

I assume included in the one I linked, mine do, but check the manifest of each to assess suitability regarding other packages, master snapshots do not.

2 Likes

This is positive news, thanks for sharing. I always keep an eye on your posts here as well as @anomeome for solid information from both of you.

I like the idea of running master snapshots.

Would it be worthwhile to have a thread here regarding these affected devices where any of us users could test snapshot builds and share details about stability, bugs, etc.?

I just want to give a heads up regarding the WRT32X and the kernel 5.15 snapshot builds. I've run into what I think is a bug, but I'm still trying to nail it down.

It only seems to manifest if there is more than 1 VLAN in use on the LAN switch with WiFi traffic assigned to each. WiFi client ethernet frames are not being untagged before leaving the switch. Interestingly, the first frame is properly untagged, but remaining frames are not. All locally generated traffic from the router is properly untagged. Adding a managed switch downstream configured to untag the traffic fixes the issue, but this obviously isn't desirable.

I still haven't ruled out user configuration error. However, the same config which works properly under 22.03.2 does not work with any of the recent snapshots that I can find.

1 Like

The right eyeballs are unlikely to see this buried in this old thread. May want to open an issue.

1 Like

Interesting findings, wonder if the VLAN issue is an mvebu issue or for all of master. Software flow offloading is also broken not allowing any traffic if enabled. I disable it and use SQM cake though. Obviously we can expect bugs since it's a ways off for a 23.xx release. Certainly it's a better experience than 22.03 for our target.

I agree and plan to once I know I'm not the cause. I posed here in case others ran into the same issue or were considering the jump to Snapshot.

Yes, my first thought was that maybe this was somehow in relation to flow control. However, this issue still occurs even with SQM and flow offloading disabled.

Post relevant configs, I think at this point I have seen three unique monikers report issue, but to above point, all on a wrtpac device of some kind.

Linksys WRT32X
OpenWrt SNAPSHOT r21791-c03e458c86

/etc/config/network

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

config globals 'globals'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option delegate '0'
        option ipaddr '192.168.2.1'
        option device 'br-lan.4'

config device
        option name 'wan'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'wan'
        option device 'wan'
        option proto 'static'
        option ipaddr 'x.x.x.x'
        option netmask '255.255.255.252'
        option gateway 'x.x.x.x'
        list dns '1.1.1.1'

config interface 'guest'
        option proto 'static'
        option ipaddr '192.168.3.254'
        option netmask '255.255.255.0'
        option type 'bridge'
        option device 'br-lan.3'
        option delegate '0'

config interface 'dmz'
        option proto 'static'
        option device 'lan1'
        option ipaddr '192.168.0.254'
        option netmask '255.255.255.0'

config bridge-vlan
        option device 'br-lan'
        option vlan '4'
        list ports 'eth0:t'
        list ports 'lan4'

config bridge-vlan
        option device 'br-lan'
        option vlan '3'
        list ports 'eth0:t'
        list ports 'lan3'

/etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
        option band '5g'
        option htmode 'VHT80'
        option country 'US'
        option cell_density '0'
        option channel '36'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxxxxxxx'
        option encryption 'psk2'
        option key 'xxxxxxxx'
        option skip_inactivity_poll '1'
        option disassoc_low_ack '0'
        option wpa_disable_eapol_key_retries '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
        option band '2g'
        option country 'US'
        option htmode 'HT40'
        option channel '11'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxxxxxxx'
        option encryption 'psk2'
        option key 'xxxxxxxx'

config wifi-device 'radio2'
        option type 'mac80211'
        option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'
        option channel '34'
        option band '5g'
        option htmode 'VHT80'
        option disabled '1'

config wifi-iface 'default_radio2'
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'xxxxxxxx'
        option encryption 'none'

config wifi-iface 'wifinet3'
        option device 'radio1'
        option mode 'ap'
        option encryption 'psk2'
        option key 'xxxxxxxx'
        option network 'guest'
        option ssid 'xxxxxxxx'

I'll do another tcpdump and see if I can capture the initial valid frame and the subsequent invalid frames.

EDIT - I got lucky and was able to reproduce it

13:34:58.132565 b8:27:eb:dc:ef:ea > 7a:50:df:d0:bc:cb, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42690, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.2.211 > 192.168.2.2: ICMP echo request, id 31467, seq 1, length 64

13:34:58.132612 7a:50:df:d0:bc:cb > b8:27:eb:dc:ef:ea, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 24968, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.2.2 > 192.168.2.211: ICMP echo reply, id 31467, seq 1, length 64

13:34:59.137439 b8:27:eb:dc:ef:ea > 7a:50:df:d0:bc:cb, ethertype 802.1Q (0x8100), length 102: vlan 4, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 42772, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.2.211 > 192.168.2.2: ICMP echo request, id 31467, seq 2, length 64

13:35:00.146242 b8:27:eb:dc:ef:ea > 7a:50:df:d0:bc:cb, ethertype 802.1Q (0x8100), length 102: vlan 4, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 42806, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.2.211 > 192.168.2.2: ICMP echo request, id 31467, seq 3, length 64

For context, 192.168.2.211 is a wireless device and 192.168.2.2 is a wired device. Both are on the LAN network and not the Guest network. The packets were captured on the wired device.

As you can see, the first packet (ping from wireless to wired) exits untagged properly which allows the wired device to respond properly in the 2nd packet. Immediately after that, all following packets are still wrapped in VLAN 4 and the wired device doesn't know to respond.

eth0 questionable (wrong), rejigged a bit to get closer to the mark:

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'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan3'
        list ports 'lan4'

config bridge-vlan
        option device 'br-lan'
        option vlan '4'
#       list ports 'lan4:t'
        list ports 'lan4:u*'
        option alais 'lan'

config interface 'lan'
        option device 'br-lan.lan'
        option proto 'static'
        option ipaddr '192.168.2.1'
        option netmask '255.255.255.0'
        option delegate '0'

config bridge-vlan
        option device 'br-lan'
        option vlan '3'
        list ports 'lan3:t'
        option alais 'guest'

config interface 'guest'
        option device 'br-lan.guest'
        option proto 'static'
        option ipaddr '192.168.3.254'
        option netmask '255.255.255.0'
        option delegate '0'

config interface 'dmz'
        option proto 'static'
        option device 'lan1'
        option ipaddr '192.168.0.254'
        option netmask '255.255.255.0'

config device
        option name 'wan'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'wan'
        option device 'wan'
        option proto 'static'
        option ipaddr 'x.x.x.x'
        option netmask '255.255.255.252'
        option gateway 'x.x.x.x'
        list dns '1.1.1.1'

just to indicate where issue(s) may be, don't take verbatim; PVID on lan4 from your description, but uncertain.

So this is a bridge-over-vlan-over-bridge setup, so that WiFi APs are placed in the correct VLAN. Can you reformulate this with only one level of bridging?

I originally had eth0 removed from the bridge, but thought it may help. Regardless, here is my current /etc/config/network:

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

config globals 'globals'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option delegate '0'
        option ipaddr '192.168.2.1'
        option device 'br-lan.4'

config device
        option name 'wan'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'wan'
        option device 'wan'
        option proto 'static'
        option ipaddr 'x.x.x.x'
        option netmask '255.255.255.252'
        option gateway 'x.x.x.x'
        list dns '1.1.1.1'

config interface 'guest'
        option proto 'static'
        option ipaddr '192.168.3.254'
        option netmask '255.255.255.0'
        option type 'bridge'
        option device 'br-lan.3'
        option delegate '0'

config interface 'dmz'
        option proto 'static'
        option device 'lan1'
        option ipaddr '192.168.0.254'
        option netmask '255.255.255.0'

config bridge-vlan
        option device 'br-lan'
        option vlan '4'
        list ports 'lan4:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '3'
        list ports 'lan3:u*'

Unfortunately, the end results are the same.

I do not currently have option alias 'lan' or option alias 'guest' inserted. I will try that next.