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

commit comment may be of interest in the firefight.

1 Like

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

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

1 Like

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

@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/

1 Like

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

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.

@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.

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.

1 Like

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!

1 Like

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

1 Like

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

@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.

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.

1 Like

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).

1 Like

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.

1 Like

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.

3 Likes

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.

1 Like

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

@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.