Hacker News Reader

Comment by Arnavion | Hacker News Reader

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

View on HN

Is there a patch for the kernel 6 line to add back the lar_disable functionality?

This was the patch that removed it:

https://github.com/torvalds/linux/commit/f06021a18fcf8d8a1e7...

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.

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.

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

    setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

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.

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?

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.

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.

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)

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.

# iw reg get

global

country 00: DFS-UNSET

        (2402 - 2472 @ 40), (6, 20), (N/A)

        (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN

        (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN

        (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN

        (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN

        (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN

        (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN

        (57240 - 63720 @ 2160), (N/A, 0), (N/A)

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

In my .config:

CONFIG_EXTRA_FIRMWARE="iwlwifi-so-a0-gf-a0-72.ucode iwlwifi-so-a0-gf-a0.pnvm regulatory.db (...)

regulatory.db exists in the expected path and the md5sum 968432874991bf18d99a4f508fb1515d seems correct.

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

> 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 move and travel? My hardware will do super illegal things if I can’t change the regions.

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.

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

Can this "open" option to switch firmware even cause any real damage? Millions of people travel each year with those chips and nothing happens?

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.

Reply on news.ycombinator.com