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

anomeome · November 13, 2021, 8:22pm

commit comment may be of interest in the firefight.

arinc9 · November 13, 2021, 8:35pm

That's a patch fixing system hangups on devices using brcmfmac, irrelevant to this issue.

arinc9 · November 13, 2021, 8:36pm

Why don't we make a commit on top of v21.02.1 and distribute the precompiled image instead of the kernel module packages?

anomeome · November 13, 2021, 8:36pm

My reference was to the 2 config debug options, not the contents of the commit.

adworacz · November 13, 2021, 8:51pm

@arinc9

That’s what I already did. I posted the link to an image a few posts ago.

I’ll post them again:

https://openwrt.austindw.com/linksys-wrt/working-wireless/r16325/

arinc9 · November 13, 2021, 8:53pm

Where's the repository with the commit that produces this image?

adworacz · November 13, 2021, 8:56pm

I haven’t published a repo. But I published instructions at the same link for anyone to reproduce themselves using a fresh git checkout. Scroll down on the first link, you’ll see them at the bottom.

adworacz · November 13, 2021, 8:58pm

@trinidude4 hmm dang, thanks for trying. Sounds like we’ll need to do more digging on how a stock image can be updated. It’s possible that it can’t if the kernel is being modified somehow.

At least we can rely on the image builds for now to provide a working environment.

arinc9 · November 13, 2021, 9:58pm

Thanks for you & @WildByDesign's weeks of work to pinpoint the problem to the 5.8 backports.

I believe using the mac80211 package as a whole instead of just pulling the patches is a better idea.

To compensate that, I've pushed two commits on my branch

First one replaces mac80211 with the state of when the "update to backports-5.7.5-1" commit was issued.
Second one removes unnecessary code from compiling, which actually fails to compile, from the Makefile.

Everything compiles fine. I plan to update my post with the images compiled from this branch soon.

WildByDesign · November 13, 2021, 10:04pm

You're welcome. Thank you as well for opening this thread in the first place which has brought the mwlwifi community together to assist in troubleshooting and testing. Also, this thread has given me a lot of motivation to not give up on mwlwifi. Cheers!

arinc9 · November 13, 2021, 10:32pm

Images are up on the main post, everyone is welcome try and see if wireless works without the cut-out issues.

arinc9 · November 13, 2021, 10:46pm

I think we should announce this build on the Community Builds section since people with WRT32X/WRT3200ACM will definitely want this.

What do you think?

@WildByDesign @adworacz

WildByDesign · November 13, 2021, 10:55pm

@arinc9 Yes, I was thinking the same thing. I think that it does need a thread on the Community Builds section.

Possibly, we can still use this current thread to troubleshoot the mwlwifi issues with mac80211 5.8+. Although I honestly am out of ideas and have very little energy left for that. I am not even sure if it will ever work with mac80211 5.8+.

So you can go ahead and announce the builds. I noticed that you did not have sha256 hashes for your builds though with your downloads. I think that would be a good idea.

I have a couple of questions for you since I am not a developer and don't understand all of the technical stuff.

How much effort, in the future, would be needed to bring in the latest mac80211 from the 5.7.x series into the OpenWrt codebase, which I believe is 5.7.19?
What exactly is the difference between your builds and @adworacz builds? Is it the same result in the end? Are your builds a cleaner implementation for the way that mac80211 5.7.5 was brought in?

Sorry for questions. I am just curious about some of those things that I just don't understand fully at the moment. Thanks.

arinc9 · November 13, 2021, 11:07pm

Sounds good, I'll put a link to this post for troubleshooting purposes.

Good idea, I'll do that.

I honestly don't know.

I did hint at the difference but not clearly explain how it's different. The main difference is @adworacz's method uses mac80211 5.7.5's patches instead of the current ones. Then, it modifies the makefile to use backports-5.7.5 instead and get rid of code which won't compile.

What I do is, I completely replace mac80211 with mac80211 at the state of the "update to 5.7.5" commit. That's my first commit.
The second commit removes unnecessary code from compiling, which actually fails to compile, from the Makefile.

I just believe that this is a cleaner implementation.

adworacz · November 13, 2021, 11:07pm

Right now my current two builds aren’t 100% compatible with 21.02.1 repos. So I’m going to try producing a new image that uses Openwrt’s build config instead of my custom one. This might be what @arinc9 already did, not sure (on a phone, haven’t checked).

arinc9 · November 13, 2021, 11:14pm

You're talking about the packages (specifically kernel modules) from the OpenWrt feeds not matching the kernel sha hash right? That's because the kernel module packages from the feeds were compiled with the untouched kernel made for 21.02.1. We modify mac80211 which is a kernel package, so we have a modified kernel running which naturally has a different sha hash.

There's no solution to this except, you force opkg to install kmod packages anyway with the --force-depends option.

slh · November 14, 2021, 12:48am

That should be relatively easy, but it won't buy you much - v5.7.x was not an LTS kernel, its maintenance stopped in late August 2020 - no bugs (security or otherwise) have been fixed or even tracked beyond that. As maintenance of stable (or LTS) kernel isn't quite linear, after all development happens in linus/ master and is only backported later, it's not very likely that going from 5.7-rc1 to 5.7.19 would gain you more insight (especially with the short attention span it has gotten).

The elephant in the room remains that v5.7 is functionally speaking a dead-end, downgrading the wireless subsystem to that state will only work for kernel v5.4 - with master already being on v5.10, it really should only be used for debugging (and maybe as a temporary band aid on the road towards a proper solution), but it's not (and can't be) a long(er) term fix.

adworacz · November 14, 2021, 3:20am

Yeah I was. I'm currently running into some unrelated build issues when trying to use the official config.buildinfo file, and I'm just done for the day.

We have both yours and my builds right now, with your changes being immortalized in your git repo at this time. I'd say we're in a "good enough" state right now. I'll update my site to call out your builds as well.

Thanks for getting your repo put together and more builds created. Having community builds for this makes sense, so everyone can benefit. Glad that our hard work has paid off.

We might eventually get to the point where we can start testing mac80211 5.8 commits, but I'm not sure how easy it will be to pull that off given the backporting system that OpenWrt uses.

kubrickfr · November 14, 2021, 9:41am

Yes, getting actual cutouts, the phone has to reconnect, make a new DHCP request and all.

This is the wifi config:

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11a'
	option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
	option htmode 'VHT80'
	option country 'FR'
	option channel 'auto'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option macaddr '60:38:e0:xx:xx:xx'
	option ssid 'xxx'
	option disassoc_low_ack '0'
	option encryption 'psk2+ccmp'
	option key 'xxx'
	option skip_inactivity_poll '1'

And logs are full of

Sun Nov 14 09:38:48 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a IEEE 802.11: associated (aid 3)
Sun Nov 14 09:38:48 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 72:9d:f1:d4:19:4a
Sun Nov 14 09:38:48 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a WPA: pairwise key handshake completed (RSN)
Sun Nov 14 09:38:48 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 72:9d:f1:d4:19:4a
Sun Nov 14 09:38:48 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a IEEE 802.11: disassociated
Sun Nov 14 09:38:48 2021 kern.debug kernel: [64654.882749] ieee80211 phy0: staid 3 deleted
Sun Nov 14 09:38:49 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 14 09:38:54 2021 authpriv.notice dropbear[20213]: Password auth succeeded for 'root' from 192.168.199.132:49456
Sun Nov 14 09:39:20 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a IEEE 802.11: associated (aid 3)
Sun Nov 14 09:39:20 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 72:9d:f1:d4:19:4a
Sun Nov 14 09:39:20 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a WPA: pairwise key handshake completed (RSN)
Sun Nov 14 09:39:20 2021 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.199.155 72:9d:f1:d4:19:4a
Sun Nov 14 09:39:20 2021 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.199.155 72:9d:f1:d4:19:4a Davide
Sun Nov 14 09:39:20 2021 daemon.info hostapd: wlan0: STA 72:9d:f1:d4:19:4a IEEE 802.11: authenticated
Sun Nov 14 09:39:21 2021 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.199.155 72:9d:f1:d4:19:4a
Sun Nov 14 09:39:21 2021 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.199.155 72:9d:f1:d4:19:4a Xxxx

maxromanovsky · November 14, 2021, 1:47pm

@adworacz @arinc9 cross-posting here.
How shall I install additional kernel module? I need kmod-tun in particular, as it's required by openvpn-openssl.
Once installed with opkg update && opkg install --force-depends openvpn-openssl , and configured with openvpn profile, router goes into an endless reboot loop.