>looks like lar_disable functionality was removed as of 5.5 kernel as a way to fix the firmware crash issue with iwlwifi, is that right?
>[...] i've tried replacing the wifi adapter but this happens on intel wireless-ac 3165, 8265, and 9260 dual band 160Mhz (currently installed adapter).
>[...] On Intel ax210ngw all 5ghz channels are disabled and cannot be used to transmit
So it's iwlwifi specifically.
>i should add that this happens on both windows and linux but at least on linux i had a way of disabling LAR so my regulatory domain gets detected properly and all the wifi channels/widths works as they should.
>[...]
on all 5.3 and earlier kernels, using lar_disable=1 all my channels work and i get a full 1733mbps link speed (5ghz ch.36 at 160mhz)as shown here
So it's not a Linux-specific issue. Rather it seems to be buggy firmware, and a method that OP was relying on to work around that bug was disabled because it was causing other issues with said buggy firmware.
But this commit message is burying the lede a bit. There are two problems here:
1) you can revert the change, but a large part of the regulatory logic lives in the firmware blob running on the chip and you can not change this.
2) the FCC doesn't look kindly upon functionality that ignores regulatory limits being available to end customers. It was already not legal for Intel to add this in the first place, and they certainly won't help you reinstate it.
The second part might be why these devices have been in a "broken" regulatory state forever now where they stay away from everything that touches upon e.g. DFS; someone at Intel might have realized that letting users pick their regulatory region is already not something they should be offering.
The reality is that these WiFi chips should probably have some fuse in them that decides what regulatory region they were made for and then run off that, but you can see the business people losing their mind over that: now you need to have a hundred different SKUs and worse you need to understand your distribution chain. So a software setting it is, and then you see why the FCC is upset.
Can I just point out how insane this method of determining the regulatory rules is...
Considering the average user would never bother to set their correct regdomain when they buy a crap Chinese wifi router, you are pretty much guaranteed to always be using the wrong (mostly CN) regdomain, because that's what your neighbours are using...
> you are pretty much guaranteed to always be using the wrong (mostly CN) regdomain
Exactly. The software should make it easier for the average user to do the right thing. Most people would select "US" in a dropdown menu if offered the chance. The windows driver could also pass the information to the firmware using geolocalization or the windows locale settings if what the firmware setting suggested by default seems awfully wrong (ex: CN regdomain while Windows locale = US, geo IP = US, GPS=US etc)
> The reality is that these WiFi chips should probably have some fuse in them that decides what regulatory region they were made for and then run off that, but you can see the business people losing their mind over that: now you need to have a hundred different SKUs and worse you need to understand your distribution chain. So a software setting it is, and then you see why the FCC is upset.
So you need to travel with like a dozen WiFi cards? Setting the region in software is a feature to all travelers...
Governments and businesses make international travel more inconvenient through the trade offs they make because most people don’t travel. Selling a solution to these cross border problems is another revenue stream.
Some appliances aren’t 100-240V. Geolocation enforces region based pricing. Cell phone plan costs vary by several orders of magnitude.
Those problems are valid, but LAR is currently often unable to detect the correct location. Even though it seems to fail to a very restrictive default, it might not, potentially causing even worse problems than a (rare) manual override would.
It also doesn't seem to be that much of an issue for other vendors to allow the user to configure their regulatory locale, it definitely raises the question how necessary this current approach is.
In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated.
> In the end, Intel's current LAR implementation hurts users that want to use their hardware within their locale's regulatory limits. It does not prevent intentionally misleading the LAR implementation or acquiring other equipment to be disruptive. To me it seems to achieve very little positive, and I've not even touched the freedom aspect of Linux being violated.
Fully agreed with all this. If there's no existing patch for the 6.2 kernel I'll make my own later today because for whatever reason my Intel wifi card thinks it's not in the US (!!!) and I want it to obey the FCC limits.
I've tried but failed to add regulatory.db to my bzImage:
# dmesg | grep regula
cfg80211: Loading compiled-in X.509 certificates for regulatory database
platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
cfg80211: failed to load regulatory.db
My regulatory.db (and regulatory.db.p7s) lives in /lib/firmware; have you tried copying it there? And I make "iwlwifi" a loadable module, so the userspace firmware loader can pick up the various firmware blobs once the rootfs is loaded (not a big fan of initrds).
I'm trying to compile that in the kernel for some reasons related to startup optimization.
The kernel sees them, and compiles them, and it WORKS with other things requiring a firmware like i915 with the HuC and the GuC, but not for regulatory.db
But what if someone moves or simply uses hardware in a different region that's sold? What if the laws change?
The correct 'work around' is to build a kernel with a DEFAULT regulatory domain, abstract from any vendor's specific implementation, allow that domain to be updated at runtime (particularly for mobile devices), and follow the laws there in. I also advocate (in this post) for wifi_regulations=BREAKTHELAWANDDISABLE (allcaps required) to completely bypass filtering channels. This would be useful in some situations such as isolated testing environments, use in International Waters, and any other environment that's isolated enough.
Keep in mind that for stations only (e.g. mobile devices most of the time), the rules are relaxed: if the station sees an AP operating on some channel, it is allowed to assume that it can operate on that channel. And of course passively scanning a channel to check for the presence of an AP is not transmitting, so no regulatory problem there.
But don't worry, for 6 GHz the FCC has come up with even more insane stuff: if you want to unlock more channels and power, your AP will have to (1) geolocate itself and (2) contact a central server to determine regulatory restrictions for that location. They are calling this Automatic Frequency Coordination (AFC). See page 13 of https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf:
> We will require the AFC to use a centralized model where each standard-power access
point remotely accesses an AFC to obtain a list of available frequency ranges in which it is permitted to
operate and the maximum permissible power in each frequency range
Why does the FCC even care so much? What nefarious things can the average consumer possibly do that a motivated attacker can't already do? A motivated attacker who wants to change all the street lights to green will have hardware that lets them do whatever they want. The other 99.999% of people will just use their system as configured by their software vendor, legally. Why do we need hardware failsafes? Why do we need certifiably absurd things happening at the driver level like AFC? It's not like this is a health and safety issue--these consumer devices shouldn't be capable of transmitting that much radiation regardless. So why does the FCC care so much? Is there a history of disaster related to consumer radios operating illegally that I'm unaware of?
Setting aside issues that can be safety related where consumer equipment overlaps with legacy equipment, there is a tragedy of the commons effect to not attempting to regulate radio power limits.
It's incredible how well WiFi works for the amount of power it uses.
Obviously turning up the transmit power makes it better... for that one person. For everyone else, that channel has a little bit more noise than before, making it harder to receive their signal.
So maybe their neighbors will also want to increase their transmit power to get better range / speed again. Having a limit across the board for all mass manufactured devices prevents an escalating spiral of vendors selling 30, then 40, then 50dbm etc routers.
As mentioned elsewhere, different countries have different power limits, but it's more economical to make a single radio for all markets with software power limits. One hypothetical way for a vendor to get a market advantage is to sell a radio that is software limited, but wink wink can be patched with easily googled instructions to increase the power to work better. Maybe by downloading a tool from some sketchy website that even actually works and can be spammed across the internet or social media.
So the FCC has to strongly discourage anything that could lead to lots of radios deliberately exceeding the regulatory limits and disproportionately making the spectrum worse compared to a compliant device.
I don't think that necessarily justifies rather invasive schemes like geolocated AFC, but preserving the use of the radio spectrum so that everyone can make efficient use of it is the FCC's mandate.
> It's incredible how well WiFi works for the amount of power it uses.
Actually, WiFi disproves that we'd have a tragedy of the commons.
> Having a limit across the board for all mass manufactured devices prevents an escalating spiral of vendors selling 30, then 40, then 50dbm etc routers.
No, the AP and the device both have a strong interest to limit the power used: not just to limit interference with other devices inside the home, but also to increase battery life!!
> but wink wink can be patched with easily googled instructions to increase the power to work better
I just don't understand why most posters here assume the worst by default. Most people are nice and want to obey the law.
WiFi proved that very little legal oversight was necessary to make it work.
In fact, it did the opposite: by comparing the efficiency of the use of the 2.4Ghz band (noisy with microwaves etc) to the rest of the spectrum managed by the heavy hand of the FCC, any reasonable person would argue for removing regulations or more parts of the spectrum (starting maybe with the huge chunks waste on HAM radio!)
> No, the AP and the device both have a strong interest to limit the power used: not just to limit interference with other devices inside the home, but also to increase battery life!!
For home routers this is a weak argument. Since most people download more than they upload, you could probably send a weaker signal from mobile devices and drown the air with signal from anything plugged into a wall socket.
> I just don't understand why most posters here assume the worst by default. Most people are nice and want to obey the law.
Maybe it's just where I live, but I don't see that on the road (people risking accidents to gain 30 seconds). People will only follow the law if they think it's worth their inconvenience and lots of people weight this in a bad way.
How many hand-tuned APs does it take to make a whole building lose significant bandwidth? After this the regulation has to become looser so the legal devices can keep working, and it never really gets better.
> you could probably send a weaker signal from mobile devices and drown the air with signal from anything plugged into a wall socket.
How exactly is your mobile device going to ACK those received packets? The mobile device needs to transmit as loudly as the AP for its ack to be received.
Boosting the transmit power higher than your receiving device can transmit leads to very bad wifi links, where the mobile device is receiving a good signal but it's own messages are not received back.
You can use different modulation rates to/from a device (this commonly happens). Lower modulation rates give you better SNR, letting your quiet client do slow weak ACKs to loud large chunks of data from the router.
The FAA raised a huge stink recently because they weren’t ready for 5G rollout and were worried that the altimeter radar would give false readings on approach to landing.
Agencies — even when in the wrong — can throw their weight around and demand that the FCC ban things.
Consumers like you and me have no real representation in government so we have no political clout and can’t throw our weight around to demand simpler legislation.
> The FAA raised a huge stink recently because they weren’t ready for 5G rollout and were worried that the altimeter radar would give false readings on approach to landing.
If the FAA didn't do its job and certified altimeters that shouldn't have been, as the 5G rollout was announced and previsible, maybe they should start working instead of complaining that others help them do their job?
Also, if all it takes to mess with altimeters is a rogue 5G cell, the right approach is to harden the altimeters, instead of hoping no 5G cell ever will be misconfigured or pushed wrong configuation parameters by a enemy country or ransomware hacker group.
> Also, if all it takes to mess with altimeters is a rogue 5G cell, the right approach is to harden the altimeters, instead of hoping no 5G cell ever will be misconfigured or pushed wrong configuation parameters by a enemy country or ransomware hacker group.
Wow, that is a lot of misconception about the threat model and real issue at hand packed into a single sentence.
First of all, great, let's say you're right. How do you harden the existing altimeters out there, equipped on thousands of aircraft? These are sensitive, tightly controlled and life-critical instruments. Radar altimeters have been in use for decades, almost a century now, and so the FAA is for the most part talking about already installed altimeters which were designed far before 5G was ever a thing. Likely most of their designs will not readily accommodate hardening against new kinds of RF interference. If you managed to patch all the different kinds out there and get fixes pushed out, that'd be a great effort in labor, logistics, and certification. Of course, one could simply replace the old radar altimeters with new ones, at a much greater cost too.
Separately from the difficulty of actual hardening, there's the question to be asked of, why ask old technology to adapt to new one when we can adapt the new technology to suit the old? Especially because, again, these are safety critical instruments that you don't wanna mess with, whereas 5G towers are much better suited to new experiments or fixes, or just being designed correctly and safely from the get go when the technology hasn't even launched yet.
And then, why do you think this is a security issue, as in an attacker aiming to disrupt air travel? You must be aware that most all aviation radio comms are in the clear and extremely easy to jam and spoof, including critical instrument systems like ILS. That is not the threat model! The FAA is worried about interference from ordinary people trying to use their cellphones, rather than a specialized attacker targeting radar altimeters. Of course, because these are two very different situations!
You should do some reading on the altimeters in question. They were operating well outside their defined limits and parameters. If they had conformed to the specifications under which they were legally certified there would never have been a problem.
How do you harden the existing altimeters out there, equipped on thousands of aircraft?
What is the correct course of action when you discover thousands of pieces of vital equipment are badly defective? An immediate recall for all defective altimeters and, hopefully, fines for the vendors.
If you aren't breaking any laws transmitting like that in International Waters, why call it BREAKTHELAW and call out that use case? If you are breaking laws transmitting like that in International Waters, why would this setting be called out as specifically useful in International Waters?
Neither seems to make sense. (And does this come from the Microsoft team who came up with
It doesn't make sense to call the same option multiple things for such a small number of use cases; you really want the last thing, but someone might not know that in _many_ circumstances it could be against the law to use it, hence the prefix to document that.
Edit: ALSO, in case it wasn't clear... E.G. wifi_regulations=USA or wifi_regulations=CDN or wifi_regulations=GBR or some other set of country codes / match in the table of known regulations. A longer string that manually specifies allowed frequencies in some way might also work.
The problem with using a fuse instead of software is that with software you can modify the regulatory value later. Like when a device leaves one regulatory domain and enters a different one.
Wouldn't 10 cents worth of EPROM be a suitable choice? First boot, it supports the least-common-denominator channels, and you run an application with a big clicky flag icon to specify the regulatory environment. The OEM could even run this before shipment since he knows where the device is being shipped to. If you move, or travel, run the program and click a different flag.
It's not unreasonable to expect the customer to know which country he currently resides in.
> 2) the FCC doesn't look kindly upon functionality that ignores regulatory limits being available to end customers. It was already not legal for Intel to add this in the first place, and they certainly won't help you reinstate it.
Not my clown, not my circus.
If the wifi firmware thinks the regulatory area is ID (Indonesia) it's wrong anyway
> WiFi chips should probably have some fuse in them that decides what regulatory region they were made for
Yes let's block most of resale of used chip and make the problem worse by having the remaining market just be for chips for a "nice" regulatory region that has the channels you want even if it shouldn't! /s
No, the answer is to fix the sar logic so that if it gives obviously wrong results, the correct setting can be passed to the firmware.
It's up to the customer to obey the limits, and this feature wouldn't make it easy for customers to "ignore regulatory limits" but do the exact opposite: allow them to OBEY the regulatory limits while the setting clearly does the opposite for now (unless Indonesia is a subset of the US SAR settings, which I don't think it is)
If my wifi think I'm not in the US, I will tell it yes, indeed we are, and it's on me if I lie to software. Most people will not lie. Why make it harder to do the right things?
I just had an amusing daydream about routers adding GPS to handle this. And having to ask my grandma to go outside and hold her router up to the sun for a few minutes.
That was useful description of the issue. I'm running a Intel AX200 (pop!os) and it seems to be working well.
"Intel wireless cards are among the best for Linux, with support for new devices landing even before they are released. however, they have one big drawback: LAR (Location-Aware Regulatory).
basically the card detects in which country it is (and therefore the regulatory domain) based on nearby access points' ones, and doesn't let you change it manually.
the sad thing is that it often sets the card to the wrong country, which is a problem.
prior to Linux 5.5 there was an option to disable this annoying feature in the iwlwifi module (lar_disable=1), but it was removed as later firmware versions caused card crashes and Intel claimed the option shouldn't be accessible anyway
"
This is utterly absurd for an AP. It effectively implements a very poor consensus algorithm by which the nearby APs coordinate to decide what country they’re in. Of course, in the absence of any of the APs having any authoritative idea, it won’t work very well.
What insane lengths are people prepared to go to to work around this issue, and still...
> since it does not disable LAR at all, it inherits the issue of requiring a 5GHz access point to be active and near the card in order to detect a 5GHz-able country.
Macs are not a replacement for a Linux desktop, laptop or a server. They do not provide the same options nor allow you do the same things. There is some overlap, but same as you wouldn't use a Linux desktop to run the Adobe suite, Macs are poorly suited for servers, development, power users, etc.
- outside of the Apple ecosystem of course, because it's literally the only choice. For anything else, any recent Linux distro provides better tools and better UX, so why bother with Apple's ecosystem, lack of package manager that doesn't suck, compatibility issues left and right (can you run a VM on M Macs now? Kind of, sometimes, depends on how much you pay to whom; containers are still a pain), an undebuggable and uncustomisable OS, etc. etc.
Nope, you're not misunderstanding me. Lots of people are using Macs to develop, same as Windows. That doesn't make it a good platform for modern development outside of their respective platform's niches.
Regardless of whether you think Mac's are good for Linux development the maxim just because lots of people choose a poor option doesn't make it suddenly a good option still rings true.
My M1 mac Mini had constant wifi headaches, effectively the wifi did not work since disconnecting every few seconds wrecks your Zoom experience. Both Location Services and a thing called AWDL would just come in and destroy your wifi link over and over again. It took Apple over 2 years to ship a fix.
I did this in undergrad when the Wifi in my dorm room was abysmal. I used an old Mac mini and hardwired it with the in-room Ethernet and then used the Wifi hotspot mode to make a nice fast wireless network for my roommate and I.
The Mac also pulled double duty as an AirPlay receiver and Plex server. Pretty handy.
I'm so relieved to find that its not just me going crazy all this time.
Its gotten so bad that I've had to install a bloody MediaTek WiFi card in my ThinkPad just to make it work reliably.
I remember when the 8000 series radios were the gold standard for mobile wireless, all the newer AX cards have been nothing but pain and suffering.
Ok, a weird question... is it a Mediatek MT7612U (usb dongle)?
Do you get a GPS fix nearby (~0.5m) of that card (eg. on your phone next to it)?
Due to some work i had ~6 of those dongles (Alfa AWUS036ACM), and all of them put out some noise in the gps range and break my gps connection the second they're plugged into the usb port (without any ifconfig up-ing them, setting a channel or connecting anywhere).
Try anything that's well-supported by OpenWRT. Even if you don't need support for AP mode, using a chip+driver pair that meets that standard (i.e. has mature AP mode support from an open-source driver that works on multiple architectures) usually means the client mode is also fully-supported (though maybe not Bluetooth). For 802.11ac, that generally means Qualcomm-Atheros ath10k or Mediately mt76 devices, with the latter being more popular among OEMs for use in client devices.
Is there anything that's current and supported by OpenWRT? Whilst I love OpenWRT, it's support is more on the level of it works enough to tx/rx packets and not necessarily all of the hardware functionality is enabled and works as per the specification.
"All of the hardware functionality is enabled and works as per the specification" is a pretty high bar even for proprietary drivers, especially when the hardware has just hit the market.
I think there are now a few hardware platforms capable of using the new 6GHz band channels ("WiFi 6E") on OpenWRT, but I haven't checked recently and haven't been looking to upgrade any of my hardware to support that (I'm doing just fine using 5GHz DFS channels that nobody else in my apartment building is using).
I'm not sure what hardware capabilities you think are poorly supported by OpenWRT or the open-source drivers for the known-good hardware choices from the QCA lineage or Mediatek's mt76 family. Can you provide any specifics?
> I'm not sure what hardware capabilities you think are poorly supported by OpenWRT or the open-source drivers for the known-good hardware choices from the QCA lineage or Mediatek's mt76 family. Can you provide any specifics?
I can't speak for them, but I've used OpenWRT on routers with Broadcom chipsets, so I think they were saying that OpenWRT support isn't a good litmus test for drivers that support the full functionality of the hardware they're for.
I specifically said "well-supported by OpenWRT", because even the most cursory investigation of what hardware works well with OpenWRT will warn you away from buying Broadcom.
Qualcomm's Atheros descended chips are generally the best bet for Linux support, especially for use in an AP. In other words you want a chip supported by the ath10k or ath11k driver depending on which generation of wifi you want. 10k = 802.11ac, 11k = 802.11ax.
You could just as easily say that gigabit Ethernet isn't current, either. But gigE clearly isn't obsolete in the way a processor from the mid-2000s is obsolete, and likewise 802.11ac is still at least a few years away from being one of those radio standards that's so inefficient and outdated that it ought to be aggressively retired.
A friend of mine had intermitent WiFi issues for a long time.
One WiFi they could just never even find, until we figured out the Intel WiFi driver for their WiFi-Chipset contained a bug causing 2ghz WiFis on channel 13 to not be visible.
It is a tiring process to identify issues like this in drivers. Really sucks when manufacturers just do not test their software.
That’s a feature for outdoor radios so they don’t interfere with airplane radars. Not sure why it was in a laptop. As the other poster said it’s for some non-US countries.
My APs have an outdoor mode I was curious about and turns out it’s for plane radars. I was very confused when I turned it on. They were outside APs so I turned it on. I was looking at the channel interfaces and noticed missing channels.
Channels 12+ are perfectly valid for WiFi use in some jurisdictions. In fact, they're useful exactly because they mostly transmit outside the range of normal WiFi channels.
802.11n works perfectly fine with channels 1+5+9+13, letting the guard bands intersect. The 1/6/11 set common to the USA leaves plenty of guard space to prevent overlaps, but wastes bandwidth in jurisdictions where channel 12 and 13 are disallowed.
Intel sometimes gets a lot of credit from desktop Linux users for having open-source drivers, but I don't get it. Their drivers are bad, at least when it comes to graphics and WiFi. Tearing problems, graphical artifacts, and connections dropping out have all been problems I've had with Intel as long as I can remember.
I haven't had a laptop that came with an Atheros chipset in a while, so I don't know if the buyout by Qualcomm has spoiled anything, but Atheros always had way better WiFi support on Linux than Intel did. And similarly, a recent AMD GPU with the community drivers in Mesa has given me way better stability than anything Intel has put out.
Open-source drivers are nice, but good open-source drivers are worth a lot more. Go for AMD or Atheros where you can.
(That said, I've had unproblematic experiences with a lot of other kinds of Intel hardware on Linux, like SSDs, wired NICs, NUCs, and even Thunderbolt. And for the most part, WiFi has been more or less good enough for me with Intel in the past few years that I haven't bothered to replace Intel WiFi cards when they've come included in my laptops.)
Before this laptop, I used an Intel+AMD laptop which worked fine (except for AMD's driver messing up in suspend, because the architecture was uncommon and left behind in the middle of a driver model switch).
"Avoid Nvidia; if you have to use Nvidia, avoid other brands if possible" seems to be the way to go.
I'm still mad about Nvidia setting an arbitrary limit to the amount of X11 displays. There is no good reason for it other than locking their customers into data center GPUs.
Ironically, I run a machine with a Realtek Wifi 6 chip and it works great on Linux, despite everything I read online was that Realtek is to be avoided on Linux and Intel should be the go-to.
In a similar fashion, I was also luckier with Nvidia proprietary drivers on Linux than with AMD open source drivers.
Seems like HW on Linux really is a box of chocolates, you never know what you're gonna get.
Could you please give the dmesg and/or other relevant id for your Realtek device? I'm getting tired of these Intel ax2?0 issues. I'm not much of a Bluetooth user but does it also work well?
I'm currently logged into Windoze for some work but I can tell you the card is a Realtek RTL8852AE.
I can pull up the dmesg info later tonight when I reboot into linux if you want.
Bluetooth works fine on it on Linux as well between my phone and my Sony headphones. No complaints from me on Fedora/Opensuse.
Out of curiosity, what issues are you having with the Intel AX chip? I also have it on my Lenovo Intel work machine running Ubuntu 22.04 and it seems OK to me.
I've been happily running KDE Neon with Nvidia drivers, last set of updates had some weird dependancies and I powered through by removing and replacing the conflicts...
Took me 3 days to get back to a GUI at boot, turns out I needed to delete the xorg.conf file.
The problem with realtek chipsets is that many of them just have no in-kernel driver, so you have to use some questionably maintained out of tree driver from github or whatever.
Soundslike you got one of the chipsets that has in-kernel support, so that is good.
Ok so yeah that is my main complaint about the Realtek cards.
If the out of tree driver becomes unmaintained / incompatible with future kernels, you are SoL. Also dkms is kind of a headache to deal with. Not sure if Nobara builds the module for you, but on traditional distros you would have to build the module via dkms on each kernel update, which again I have to repeat is not guaranteed to actually succeed.
do you by chance have any experience with the realtek ethernet? I too have seen the conventional wisdom around avoiding the realtek chips. I'm looking to build a linux box (hopefully) soon and filtering out mobos with realtek chips is difficult
They used to be glitchy, I've had okay success with them. The igc module (new igb) is a buggy nightmare on Linux with the kmod maintainers having no idea how to run a speed test with forwarding to also kernel panic... It's really bizarre.
Intel's consumer-oriented Ethernet has also been a disaster on the hardware side lately, with basically all of their 2.5GbE chips having serious bugs. At this point, it seems like Realtek is the sane choice for 2.5GbE, or Aquantia/Marvell for 5/10GbE.
My old Intel laptop from 2016 had a Realtek ethernet gigabit chip and Linux rand fine on it. I don't have it anymore to confirm which chip exactly, nor do I think they still sell that today.
Not related to wifi, but Intel broke the IPU6 webcam on Linux also. I have a Dell XPS13 - on the initial Ubuntu they shipped with, it was working, but after a dist-upgrade it stopped. There's lots of traffic out there, with some reports that it started working again with the 6.1 kernel, but on mine (with Dell drivers and 6.2 kernel) it's broken.
There was another Intel related issue with this laptop also; the gpu would freeze/panic intermittently, multiple times a day. This was "fixed" by adding a boot flag in grub to turn off a certain feature, and I think the ultimate fix may be working its way into the kernel currently.
Really not the slick experience I was hoping for with the XPS13. I mostly work on my desktop so it's not the end of the world, but it has me thinking about getting a mac in 5 or so years, assuming Asahi reaches stability.
> There was another Intel related issue with this laptop also; the gpu would freeze/panic intermittently, multiple times a day.
I had this on my Dell XPS13 (9310) as well, although in my case it was a few times a week, maybe .5 times a day. It also seemed to almost always trigger when kwin was animating something, particularly switching to another virtual desktop, but never when playing any games. I can't imagine why, but the problem mostly went away when I turned off all animations in kwin, and seems to have gone away completely sometime about a year or so ago.
All in all, it's still a better experience than the Macbook Air I was using prior to having this XPS13... That damn Macbook loved to vomit onto the screen and lock up without warning. No dust, thermals seemed fine, battery was healthy... no clue what was wrong with it. And without many exposed settings to fiddle with.
Chromebooks are the only laptops you can usually expect to work correctly and integrate every peripheral with Linux. Which, no surprise, is why IPU6 cameras work on Chromebooks. It's open source and everything.
The reason these things are often broken on Ubuntu and the other distros is simply that the governance and organization of those projects is not incentivized to ship a working product.
This frustrated me for over a year. I moved to a house and wanted to give my gf a reprieve from the wires I used to run through our apartments. But, I’ve been dealing with connection drops and speeds of around 1.2 Mbps.
I figured it was the walls until I setup a “slow” 2G network for an old printer and my PC was at full speed when connected to it. Figured out that it was a driver issue a few weeks ago. This is a problem I haven’t had since around 2000. Never would have guessed that the device I chose for compatibility and support would have a driver that flakey.
Ahh, that's about the time IIRC that Dell started soldering in their wireless chips on the XPS 13. Previously you could swap them out for a different chip with better drivers, now you're stuck.
My guess is they are using Intel CNVi (https://en.wikipedia.org/wiki/CNVi), which moves some of the WiFi/Bluetooth hardware into the CPU/Chipset. It saves money.
What do you mean by saves money? Couldn't Intel be using shenanigans (i.e. anticompetitive price incentives) to get device makers to use this type of card, so the device makers are then tied to Intel wifi and can't switch without redesigning their motherboard?
I’d argue SSG and caching are the same solution just a difference in where the cache resides (disk vs memory) and warming strategy (on-demand vs preemptive)
How often does a bug tracker get that much traffic? And using an SSG for one when tons of the queries will have specific filtering terms doesn't seem so great either.
To be honest, I bought a new laptop when AX 5GHz releaded and installed my own Linux work setup. Boom wifi interl disconnects every 5-10min on 5Ghz. I had reconnect manually because do some issues with drivers. With the total pain I moved to windows setup. It's unbelievable that such a premium products breaks on major operating systems.
I leave wavemon running in a terminal just for sport these days to see what my ax200 and ax210 are doing. It is always a mysterious surprise to see what rx and tx values might be seen at any given time.
> "Goofy problems [...] abound for a _long time_ with seemingly no solution" is the norm in desktop Linux.
Hey, it's still better than Windows:) To quote a bit from upthread,
>>i should add that this happens on both windows and linux but at least on linux i had a way of disabling LAR so my regulatory domain gets detected properly and all the wifi channels/widths works as they should.
5 week old issue. Ed: oops, 3 year old!! (what year is it?) No useful updates.
Generally I think Intel is one of the best companies at open-source by far & it's a huge competitive advantage. But all companies of any notable size are companies of many smaller orgs... Still surprising, as Intel has excellent dedication to wifi & has great works like connman.
But also... competitive advantages only matter if anyone notices or cares. This issue is incredible egg-in-the-face to literally all of us. That everyone missed this is absurd!
Ed: now that I see the full year, pretty shameful seemingly nothing has been done in 3 years. Why?!? Ed ed: oh, only affects AP mode... OK now that's not good but way more reasonable scope!!
Thanks! Apologies. Thanks thanks thanks. I edited the post after your posting. Thanks thanks thanks.
I also didn't know at the time this was limited to AP mode. Still, it being bad for so long is ultra-embarassing. I sincerely appreciate the correction. My bad.
On a Ryzen 5 3600 desktop with two nvme drives running windows 10 & Ubuntu 22 unaware of each other it is 50-50 odd of either Bluetooth or WiFi not detected until a few reboots
Windows regularly puts and leaves radios in various low-power states that linux doesn't know about, so I generally need to cleanly shut down windows completely before booting into linux.
My ath9k stopped working after upgrading from 5.4.x to 5.15.x... 5ghz radios disabled, couldnt turn them on no matter what I tried. I figured it was because hostapd screwed something up...
I wonder if it was the same (or similar) issue... I wound up buying a mikrotik AP after all that nonsense.
I have this reproducible issue on an XPS 7590(using a Killer 1650) that when I do somehting GPU heavy, e.g. gaming, the Wifi connection will get super flaky and then stop completley. DMESG is flooded with error messages regarding wifi. I only realized this, that the Steam client has a little notification which would tell you that you went offline. I started to experiment and it works for me if I disable the 11n standard. The driver has an option to do so (modprobe -r iwlwifi && modprobe iwlwifi 11n_disable=1). Only then I can play games and have an internet connection... I am pretty sure that if this would happen on Windows, all the users would have gone balastic.
It appears this is a non-US issue? "iw reg get" shows "country 00: DFS-UNSET" with 9 frequencies (incl. 755-928 MHz ... huh) and "country US: DFS-UNSET" with a long list going from 2402-7125 MHz on my Wi-Fi 6E AX211
I was confused by this too. 5 GHz channels with 40/80 MHz width definitely work for me, without having to set a regulatory domain.
It appears that this problem is related to Intel's WiFi firmware automatic detection of the regulatory domain, which is LAR. This is done on the basis of nearby access points, although the specifics of how this works is beyond me.
The problem is that if this gets detected incorrectly, there's no way to override. What the users in this bug report found that attempting to set the regulatory domain manually resulted in two separate regulatory domains being defined, which still left the 5 GHz channels disabled on their devices.
A workaround for this firmware issue, previously, was to disable LAR, which would force the card to use the manually set regulatory domain. But this option was removed from the kernel due to it causing other problems.
So I don't think this is (exclusively) a non-US issue, it's an issue for people who live in a place where nearby access points will teach the WiFi driver the wrong regulatory domain ... however that works. It's probably less common for this to happen in the US, but not impossible.
Partially contrary to the title, I would expect this problem to affect a relatively small number of users.
A nearby AP is not always sufficient for LAR to work properly, making AP startup finicky and slow at best. While also causing the issue that scans later on might affect functionality (https://tildearrow.org/?p=post&month=7&year=2022&item=lar). I guess you could also end up with totally incorrect (and illegal) location detection, but that's less likely than it not working at all (leaving everything disabled).
With 6GHz in the mix, the likelihood of automatic detection failing to find any nearby relevant APs rises significantly. Breaking all IR (initiate-radiation) functionality, AP mode included.
> So I don't think this is a non-US issue, it's an issue for people who live in a place where nearby access points will teach the WiFi driver the wrong regulatory domain ... however that works. It's probably less common for this to happen in the US, but not impossible.
Could it be as simple as somebody moving from Indonesia or wherever to America, and bringing their Indonesian/etc AP with them?
Possibly, but it could also be one of your neighbors, or a nearby AP enabling channels that are not supposed to be enabled in the US. The issue is that when Intel's drivers make the wrong decision about the regulatory domain, you don't usually have a lot of insight about why. Seems this issue affects Windows users as well.
Ouch, I just bought a gigabyte b650 because reddit told me the intel wifi would play nicer with ubuntu than a realtek card. I don't know who to believe anymore.
This bug is for using the Intel card as a WiFi access point. For using it as a WiFi client, Intel cards still "just work," and there aren't any other good WiFi options afaik. Realtek and Broadcom do suck. Atheros used to be good a long time ago with ath9k, but I don't think they're really around anymore (?).
I'm relatively certain that the regulatory locale non/misdetection will affect station mode (power) limits as well, people will probably just notice that less often (as the main hindrance to ap mode is the "no IR" flags).
In my experience, the Intel WiFi drivers work fine, unless you want to set up an access point.
Still kind of crappy, but my experience with Broadcom is so bad that I'd rather lack the 160MHz channels (and use 80MHz) than try to get Broadcom's drivers to work right.
I’m convinced the only thing Wi-Fi doesn’t fuck out on at the moment is windows. Had problems with Linux, macs and android for the last few years. Just works on windows!
>[...] i've tried replacing the wifi adapter but this happens on intel wireless-ac 3165, 8265, and 9260 dual band 160Mhz (currently installed adapter).
>[...] On Intel ax210ngw all 5ghz channels are disabled and cannot be used to transmit
So it's iwlwifi specifically.
>i should add that this happens on both windows and linux but at least on linux i had a way of disabling LAR so my regulatory domain gets detected properly and all the wifi channels/widths works as they should.
>[...] on all 5.3 and earlier kernels, using lar_disable=1 all my channels work and i get a full 1733mbps link speed (5ghz ch.36 at 160mhz)as shown here
So it's not a Linux-specific issue. Rather it seems to be buggy firmware, and a method that OP was relying on to work around that bug was disabled because it was causing other issues with said buggy firmware.