[HN Gopher] Linux Intel WiFi driver broken with 5&6GHz bands for...
___________________________________________________________________
Linux Intel WiFi driver broken with 5&6GHz bands for longer than
three years
Author : Avamander
Score : 167 points
Date : 2023-03-17 16:40 UTC (6 hours ago)
(HTM) web link (bugzilla.kernel.org)
(TXT) w3m dump (bugzilla.kernel.org)
| mydriasis wrote:
| I knew something was up. Goofy problems with wireless abound for
| a _long time_ with seemingly no solution.
| cf100clunk wrote:
| 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.
| favaq wrote:
| "Goofy problems [...] abound for a _long time_ with seemingly
| no solution" is the norm in desktop Linux.
| oynqr wrote:
| I remember trying to find a USB wifi adapter that actually
| has WPA3 driver support on Windows. Hell.
| mydriasis wrote:
| Not really. Desktop Linux destroys every other user
| experience I've had without trying.
| yjftsjthsd-h wrote:
| > "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.
|
| (https://news.ycombinator.com/item?id=35199660)
| kennethrc wrote:
| 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
| bscphil wrote:
| 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.
|
| Edit: I found a great blog post talking about the issue in more
| detail, although it's from the point of view of hosting an AP
| on the device.
| https://tildearrow.org/?p=post&month=7&year=2022&item=lar
| stametseater wrote:
| > _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?
| bscphil wrote:
| 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.
| Avamander wrote:
| This indeed affects more than just the US.
|
| 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.
| unxdfa wrote:
| 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!
|
| Shame about all the other problems with it.
| amiga-workbench wrote:
| 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.
| silisili wrote:
| Hey same! My last minipc had intel, and it was so bad I just
| ran it in 2.4ghz mode.
|
| My latest one has an MTK chip by no choice of my own, and it
| works fantastic. Shame on Intel.
| eikenberry wrote:
| And Intel was the last reliable wifi chip maker I knew. What
| are good, well supported (on linux) wifi chipsets these days?
| amiga-workbench wrote:
| I can only speak for myself here, but I'm running a MediaTek
| MT7921 on Fedora 37, I picked it up on eBay for PS12 and its
| been spot on.
|
| Unlike my Intel AX210 I can actually get a full gigabit down
| sat next to my router.
| [deleted]
| magila wrote:
| 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.
| jrockway wrote:
| ath10k isn't current hardware, though. We used that for
| Google Fiber wifi back in 2015. The world now has "Wifi 6"
| and other such nonsense.
| Dylan16807 wrote:
| 6 is ax. So as the post says, ath11k.
| CameronNemo wrote:
| Mediatek and Qualcomm are pretty well supported afaict.
| Realtek is hit or miss. Broadcom should probably be avoided.
| wtallis wrote:
| 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.
| eptcyka wrote:
| 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_.
| oynqr wrote:
| What hardware functionality do you need that OpenWRT
| doesn't support?
| wtallis wrote:
| "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?
| ajsnigrutin wrote:
| 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).
| amiga-workbench wrote:
| MT7921 M.2 card, I've not noticed any interference, but I've
| also not been actively checking for that.
| oynqr wrote:
| It's widely known that USB3 transfers produce crippling RF
| noise. Try a USB2 port.
| stametseater wrote:
| > _all the newer AX cards have been nothing but pain and
| suffering._
|
| This is surprising for me to hear. My AX201 hasn't given me any
| trouble at all, ever. Maybe I've been getting lucky.
| ryanjshaw wrote:
| If it makes you feel better, I've had serious issues with AX
| cards on enterprise Windows ThinkPads.
| boppo1 wrote:
| 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.
| the_pwner224 wrote:
| 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 (?).
| Avamander wrote:
| 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).
| jeroenhd wrote:
| 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.
| StrangeATractor wrote:
| 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.
| CameronNemo wrote:
| Embarrassing decision. All in the pursuit of a slightly thinner
| chassis, I imagine.
| ac29 wrote:
| 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.
| pxc wrote:
| 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.)
| stametseater wrote:
| In my experience, tearing only occurs with Intel GPUs if you're
| using X without a compositor. With a compositor it isn't an
| issue.
| jeroenhd wrote:
| Compositors still have issues in some setups (mine,
| specifically: Intel + Nvidia + mux chip).
|
| On most Linux laptops with no dedicated GPU, Intel GPUs seem
| to work fine, though.
| stametseater wrote:
| Ah I see, I have no experience with dual-GPU setups.
| jeroenhd wrote:
| 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.
| sadlywebdev wrote:
| 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.
| wil421 wrote:
| 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.
| antisthenes wrote:
| > WiFi-Chipset contained a bug causing 2ghz WiFis on channel 13
| to not be visible.
|
| Don't use non-standard channels. You're making it worse for
| everyone.
| jeroenhd wrote:
| 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.
| MayeulC wrote:
| Sounds like a misconfigured regulatory zone, TBH. Channels 12
| and 13 are not legally usable in every country, including the
| USA: https://www.howtogeek.com/402142/why-wi-fi-
| channels-12-13-an...
| nubinetwork wrote:
| 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.
| hackernudes wrote:
| This is for 5ghz AP (access point) mode. As a station/client it
| works fine. A workaround here
| https://tildearrow.org/?p=post&month=7&year=2022&item=lar
| phoronixrly wrote:
| 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.
| Avamander wrote:
| It also doesn't help with 6GHz networks, the small range
| combined with relative rareness makes it basically not
| possible to use.
| throwaway5959 wrote:
| [flagged]
| sofixa wrote:
| 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.
| culturestate wrote:
| _> Macs are poorly suited for ... development, power
| users..._
|
| Am I misunderstanding you or does this not describe the
| vast majority of Mac users in Silicon Valley?
| phoronixrly wrote:
| Don't make me laugh, AFAIK Macs ship Broadcom, which is
| notoriously the only worse than Intel wifi card you can
| have.
| CameronNemo wrote:
| You use a Mac as your AP!? Sounds expensive.
| AndroidKitKat wrote:
| 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.
| jeffbee wrote:
| 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.
|
| https://systemstatus.ucla.edu/status?id=status_record&servi
| c...
| acomjean wrote:
| 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 "
| amluto wrote:
| 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.
| ChuckNorris89 wrote:
| 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.
| ajoseps wrote:
| 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
| ChuckNorris89 wrote:
| 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.
| KyleSanderson wrote:
| 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.
| wtallis wrote:
| 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.
| pnutjam wrote:
| 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.
| ValdikSS wrote:
| >works great on Linux
|
| Now try `sudo iw dev wlan0 del` and the kernel will deadlock :)
| cf100clunk wrote:
| 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?
| ChuckNorris89 wrote:
| 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.
| cf100clunk wrote:
| > RTL8852AE
|
| No that's fine, great info, cheers.
| Vogtinator wrote:
| Same RTL chip here, works absolutely fine without any
| issues.
| CameronNemo wrote:
| 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.
| ChuckNorris89 wrote:
| No I don't think it's in kernel support, I think that Nobara
| linux has been patched to support it.
|
| It's not a recommendation to go and buy a Realtek card, I was
| just sharing my anecdote.
| narutowindy wrote:
| 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.
| ranger_danger wrote:
| my laptop's bluetooth has been broken under linux ever since it
| was released in 2015:
| https://bugzilla.kernel.org/show_bug.cgi?id=99371
| Arnavion wrote:
| >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.
| csdvrx wrote:
| Is there a patch for the kernel 6 line to add back the
| lar_disable functionality?
| stefan_ wrote:
| 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.
| Avamander wrote:
| 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.
| csdvrx wrote:
| > 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.
| AlphaSite wrote:
| I move and travel? My hardware will do super illegal things
| if I can't change the regions.
| Waterluvian wrote:
| 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.
| mjevans wrote:
| 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.
| jodrellblank wrote:
| 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
|
| ?)
| mjevans wrote:
| 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.
| stefan_ wrote:
| 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
| dcow wrote:
| 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?
| devanl wrote:
| 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.
| csdvrx wrote:
| > 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!)
| plonk wrote:
| > 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.
| jiggawatts wrote:
| 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.
| csdvrx wrote:
| > 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.
| trifurcate wrote:
| > 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!
| csdvrx wrote:
| > 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?
| phoronixrly wrote:
| 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...
| csdvrx wrote:
| > 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)
| aidenn0 wrote:
| > 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...
| rektide wrote:
| 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!!
| loeg wrote:
| > 5 week old issue
|
| The link I'm looking at says 2020-02-08.
| prerok wrote:
| 5 weeks? It's actually 3 years.
| lelandbatey wrote:
| The link seems to be experiencing a mysterious outage, reporting
| "404" when I visit the page. Other bugs seem to be fine. Not sure
| what's going on.
|
| Here's a mirror:
| https://web.archive.org/web/20230317164517/https://bugzilla....
| mricon wrote:
| The admins probably got grumpy because a bajilion HN bots
| querying for link previews DDOS'ed the whole bugzilla.
| [deleted]
| nousermane wrote:
| Hug of death from HN visitors.
|
| For fellow website admins, this is your regular reminder to use
| static site generators, where possible, and server-side cache
| where not.
| berkle4455 wrote:
| 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)
| throwaway81523 wrote:
| 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.
| kevin_thibedeau wrote:
| Bugzilla routinely falls on its knees just from internal
| use.
| froh wrote:
| > where the cache resides (disk vs memory)
|
| local vs CDN that is...
| miiiiiike wrote:
| 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.
| jeroenhd wrote:
| This specific bug mostly impacts AP mode. If you can get a
| connection over 5+GHz at all, you're probably dealing with a
| different driver issue.
| villgax wrote:
| 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
| LamaOfRuin wrote:
| 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.
| cf100clunk wrote:
| I posted this solution elsewhere recently:
|
| https://news.ycombinator.com/item?id=35113567
|
| I think it is what you've been seeing.
| smallerfish wrote:
| 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.
| stametseater wrote:
| > _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.
| jeffbee wrote:
| 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.
|
| https://source.chromium.org/chromiumos/chromiumos/codesearch...
|
| 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.
___________________________________________________________________
(page generated 2023-03-17 23:01 UTC)