Netgear R8000 Wi-Fi broken after 21.02 upgrade

Hi all, I ran the 21.02 update today on my Netgear Nighthawk R8000.The upgrade itself went through ok but since then, I cannot connect any devices to the wireless interface. There are some changes you need to make on the R8000 to get WIFi working in the first place - namely making sure the radios are set to US and using specific channels on each one - but these are set as before. Everything else on the router is working like before so I'm wondering if anyone else has upgraded their R8000 onto the new firmware and have the same issue? It's a weird beast, the R8000, but it has been running like a dream for the last year or so on the previous releases. It seems to be struggling just after an attempt is made by the client for authentication - but is happening on all my mobile devices in the house.
Is it a case of rolling back for now?
https://openwrt.org/toh/netgear/r8000 is the official link to the device in question.
Many thanks in advance, TC.

Hi tonyclifton,
I just upgraded my R8000 today as well and now I dont even see wireless listed under network in LUCI.

I am wondering if there is some documentation about what you have done to get the wireless working, I dont even see radios available under LUCI. What is happening?

Hi! I bought a used R8000 a couple months ago and finally decided today to try out OpenWRT on it.
And I hit that same issue: Wi-Fi just wouldn't work (I did manage to make the network visible by switching Authentication to WPA3, but still the computer didn't seem to associate with it).
So my question is: did you figure out what was wrong? I'm thinking if it even makes sense for me to keep this router if I can only use the official firmware with it.
Cheers!

Continue experimenting without WPA3 or IEEE 802.11w, I wouldn't expect brcmfmac to support either (yes, I've read your partial success statement, but I still think this causes your more harm than gain at this stage of your problem).

Thanks!

But I'm wondering why WPA3 is even shown as an option then? If OpenWRT cannot supoort it on certain routers, it's okay, but then it shouldn't expose it as an available option on these devices, since that just causes confusion and frustration. It makes me wonder what else is exposed but not supported and whether I'm supposed to just click around randomly until the setup magically works. That's not a very good user experience, is it?

By the way, I have a Linksys WRT1900ACS as well. The main reason why I decided to replace it with this Netgear router was because its connectivity was unstable when using OpenWRT (while the stock firmware works just fine). I suspected that the latest version of OpenWRT might no longer have that problem, so I flashed it again yesterday and put it back on the wall. It seemed to work fine, but then, while I was writing this very comment, I suddenly lost Internet connection again. Other people seem to have been having similar problems way since OpenWRT 18.06.2 (discussed here and here). I'll try the solution in that second post this evening, but I do find it quite discouraging that OpenWRT seems to ship with broken available options and even defaults.

The clients that connect to the router have to support WPA3 as well.

Many don't yet.

The client supporting WPA3 won't be of much help if OpenWRT can't support it on the router in the first place, which seems to be what @slh implied.

And seeing how WPA3 has been around since 2018, I'm quite convinced that a lot of clients should be supporting it already. :slight_smile: At least my Linux machine claims to do so.

On the other hand, even the latest stock firmware for said Netgear router doesn't expose WPA3 as an option. Assuming this is an actual technical limitation of the hardware (or the Wi-Fi adapter firmware), I see no reason for OpenWRT to expose this option that doesn't actually work on this router.

See the 21.02.0 release announcement on WPA3 -

And the "caveat" in that announcement...

WPA3 is supported by most Wifi drivers in OpenWrt.

brcmfmac patch -

https://patchwork.kernel.org/project/linux-wireless/patch/20210824221330.3847139-1-czajernia@gmail.com/

Be exact with what you mean with "the latest version"...
21.02.1 has know problems, and a major one (in upstream Linux WiFi drivers since 2020) was fixed in late 2021, and fix is in 21.02.2 and master snapshots.

See this, not only wrt3200acm but actually all mvebu mwlwifi routers...

I didn't see any reference to mvebu for the Netgear R8000.

As far as I know, the sentence that I quoted was about wrt1900acs...

And the "caveat" in that announcement...

WPA3 is supported by most Wifi drivers in OpenWrt.

Yeah, but can't OpenWRT only expose the feature on the devices where it is actually supported instead of exposing it everywhere and letting the users figure out via trial and error whether it works or not?

I'm not sure why you're showing me the patch though. :grinning: I'm certainly not going the hard route of patching and compiling OpenWRT myself. I see that that patch is fairly recent. Does the kernel in OpenWRT 21.02.1 have it included already?

Be exact with what you mean with "the latest version"...

i mean the version downloaded from the WRT1900ACS page, so 21.02.1. That thread dates back to July, so I assumed a version released in October would have that fix already.

P.S. Sorry for mixing issues with two unrelated routers in the same thread. That's a bad habit of mine.

The Netgear 8000 was the device being discussed, so I must have missed the relevance of the WRT1900 ACS to the issue.

OpenWrt LuCI GUI makes rudimentary selection of shown features by querying the wifi driver for compiled-in features. But there is no device-level database about bugs/features.

1 Like

If it worked for the devices that were tested before the 21.02.0 release, should it be held back from everyone because a handful of wireless chips can't support it?

A similar argument is going on about ath10k-ct drivers. Some devices work great with them, others don't.

You would need to ask a developer that question.

The patch was for WPA3-SAE functionality.

Pretty easy to test if you have a client that also supports it.

should it be held back from everyone because a handful of wireless chips can't support it?

That is explicitly not what I was suggesting. What I was suggesting was that if it is known that a certain feature does not work on certain devices, it should be withheld from these particular devices until it does work.

Or at least the wiki pages for these devices could have a note about it.

It feels to me like you're suggesting that it's perfectly fine to expect people to read release notes a version or two back, sift through multiple threads in this forum, investigate Linux kernel patches and just try out various setting combinations until even Wi-Fi (undoubtedly the main function of most OpenWRT routers) works acceptably instead. Maybe this is indeed how it works, but I'm just pointing out that it's not ideal.

I've never had to...

...and I've used OpenWrt for several years.

I have done some research on the ath10k vs ath10k-ct drivers and made a decision to not use the defaults.

It was 2 CLI lines to execute, and done.

Your expectations may or may not be aligned with reality, but research and testing have always been my go to for getting the best out of my devices.

Again, you might direct your concerns to @jow or @hauke to get better insight on why things were done the way they were.

1 Like

In all that time spent on discussing how luci should behave, how about actually testing if disabling wpa/ 11w helps for your device?

luci can't hardcode or 'know' how each driver copes with wpa3/ 11w, it differs from chipset to chipset (with one driver usually supporting multiple chipset generations) and may differ between firmware revisions and kernel versions. Trying to chase this would do more harm than good (and before fall 2019 'all' drivers were broken to some extent, courtesy of no one having tested 11w before). It never pays off to get exotic hardware - and the r8000 is exotic and kind of old by now.

2 Likes

Your expectations may or may not be aligned with reality, but research and testing have always been my go to for getting the best out of my devices.

I guess I should start with the defaults indeed, and test each config change in isolation for at least a couple days to detect the bad ones.

In all that time spent on discussing how luci should behave, how about actually testing if disabling wpa/ 11w helps for your device?

luci can't hardcode or 'know' how each driver copes with wpa3/ 11w, it differs from chipset to chipset (with one driver usually supporting multiple chipset generations) and may differ between firmware revisions and kernel versions. Trying to chase this would do more harm than good (and before fall 2019 'all' drivers were broken to some extent, courtesy of no one having tested 11w before).

Fair enough. I'll test whether disabling WPA3 helps. Can't do it now cuz I need working Wi-Fi.

It never pays off to get exotic hardware - and the r8000 is exotic and kind of old by now.

R8000 has a device page in the wiki and is listed as supported, although with a note about Broadcom support in general.

The situation with WRT1900ACS seems very similar now that the open-source Marvell driver has been abandoned.

Is there a list of "best supported routers" on OpenWRT website anywhere? A google search brought me to an article recommending Turris Omnia, but that router is kinda on the expensive side, and it also uses a chipset from Marvell, so I just assume that driver-wise it's not much better than the Linksys.

In short; no - there's neither a runtime possibility for LuCI to figure it out nor a quirks database we can refer to.

2 Likes