Asahi Linux folks are doing us a solid with WPA3 fixes(rachelbythebay.com)
rachelbythebay.com
Asahi Linux folks are doing us a solid with WPA3 fixes
https://rachelbythebay.com/w/2023/11/07/wpa3/
46 comments
Hmm... but is that what happened, really? It seems like the WPA3 issues have been known about for a long time, and were blogged about by Rachel previously. Seems like the driver maintainer was just being um... we'll go with overly-cautious to remain charitable.
And really I would like to hear the story, from all sides, charitable (or not ...).
Look at it this way, the White House Press Corp is a large number of experienced professional journalists all trying to make sense of a chaotic [#] situation - and while you know US policy matters more than the Linux Kernel, the Linux Kernel underlies trillions of dollars of business in billions of dollars of hardware globally.
lwn is the white house press corp for Linux, it does a good job, more can of course be done but as we get more and more reliant on software the choices made by harassed maintainers becomes more important.
[#] the chaotic here is not some comment on past or current administrations in the white house - just running a f%#%%g country is going to be chaotic at the best of times.
Look at it this way, the White House Press Corp is a large number of experienced professional journalists all trying to make sense of a chaotic [#] situation - and while you know US policy matters more than the Linux Kernel, the Linux Kernel underlies trillions of dollars of business in billions of dollars of hardware globally.
lwn is the white house press corp for Linux, it does a good job, more can of course be done but as we get more and more reliant on software the choices made by harassed maintainers becomes more important.
[#] the chaotic here is not some comment on past or current administrations in the white house - just running a f%#%%g country is going to be chaotic at the best of times.
Recent and related:
Still no love for WPA3 on the Raspberry Pi 5 - https://news.ycombinator.com/item?id=38170980 - Nov 2023 (155 comments)
Still no love for WPA3 on the Raspberry Pi 5 - https://news.ycombinator.com/item?id=38170980 - Nov 2023 (155 comments)
> This is the Linux experience I remember from the 90s: poring over compatibility lists and making sure you buy the right thing every time.
I remember doing this for Solaris x86 as well.
I got a sun usb keyboard and replicated the work environment quite well at home, on cheap x86 hardware that was generally much faster than the low-tier sparc machines I had access to.
I remember doing this for Solaris x86 as well.
I got a sun usb keyboard and replicated the work environment quite well at home, on cheap x86 hardware that was generally much faster than the low-tier sparc machines I had access to.
> I remember doing this for Solaris x86 as well.
Very kewl! What era did you use Solaris x86 in, and for what reason?
Very kewl! What era did you use Solaris x86 in, and for what reason?
I'm guessing ~94 or ~96? I used it at work and was comfortable with the environment.
I see!
> I hit the store and picked one up, then came home, tested it, and wrote the post.
Some of us live in a different RPi 5 availability world apparently.
Some of us live in a different RPi 5 availability world apparently.
So am I reading this correctly that the raspberry pis and macbooks use the same wireless chipset and therefore driver, so development effort on the one is benefiting the other?
Not quite. From Marcan on Mastodon:
> So apparently WPA3 is just outright broken on Raspberry Pi: https://rachelbythebay.com/w/2023/11/06/wpa3/ [This is a link to the last article by Rachel, preceding the TFA]
> Good for me, means I can re-send our patch that rips out the (now confirmed useless and non-functional) Cypress WPA3 support and replaces it with the Broadcom WPA3 support that does actually work on Broadcom chips in Apple machines.
> We've had WPA3 in Asahi Linux since forever, the only reason it's not upstream yet is because the Broadcom maintainer guy was worried that ripping out the Cypress thing (that nobody knows about, and Cypress guys gave us the silent treatment when we sent them emails asking) would break Cypress. Looks like Cypress is already broken, so there.
https://social.treehouse.systems/@marcan/111367559488387627
So my understanding is that Broadcom (on Mac) and Cypress (on Raspberry Pi) are not the same chipset but maybe they previously shared a driver? Or something like that.
Now that they know Cypress is broken anyway, they can go ahead and fix Broadcom.
> So apparently WPA3 is just outright broken on Raspberry Pi: https://rachelbythebay.com/w/2023/11/06/wpa3/ [This is a link to the last article by Rachel, preceding the TFA]
> Good for me, means I can re-send our patch that rips out the (now confirmed useless and non-functional) Cypress WPA3 support and replaces it with the Broadcom WPA3 support that does actually work on Broadcom chips in Apple machines.
> We've had WPA3 in Asahi Linux since forever, the only reason it's not upstream yet is because the Broadcom maintainer guy was worried that ripping out the Cypress thing (that nobody knows about, and Cypress guys gave us the silent treatment when we sent them emails asking) would break Cypress. Looks like Cypress is already broken, so there.
https://social.treehouse.systems/@marcan/111367559488387627
So my understanding is that Broadcom (on Mac) and Cypress (on Raspberry Pi) are not the same chipset but maybe they previously shared a driver? Or something like that.
Now that they know Cypress is broken anyway, they can go ahead and fix Broadcom.
The Cypress chipset used to be a Broadcom product. Broadcom decided to sell the 'IoT' side of their WiFi/BT product line.
my understanding is:
Cypress bought the embedded/IoT wifi department from Broadcom, including a bunch of IP, and uses a shared wifi driver with other Broadcom wifi chipsets, with some shared maintainers. The driver in question is brcm80211
https://patchwork.kernel.org/project/linux-wireless/patch/14...
https://investors.broadcom.com/news-releases/news-release-de...
Cypress bought the embedded/IoT wifi department from Broadcom, including a bunch of IP, and uses a shared wifi driver with other Broadcom wifi chipsets, with some shared maintainers. The driver in question is brcm80211
https://patchwork.kernel.org/project/linux-wireless/patch/14...
https://investors.broadcom.com/news-releases/news-release-de...
The whole WiFi story on Macs is beyond silly. I recently did this on a recent model Macbook Air after installing Linux on it and ended up with a dock and an ethernet cable because I needed the files that were present on the box before installing linux because there are so many variations that this is the only failsafe way to get WiFi that actually works.
Not quite but kinda.
They use the same vendor. There are actually a few folks who use the same chips but produce different firmware (was broadcom, infineon, cypress, cypress bought broadcom's IP, and then cypress was later bought by infineon so now it's broadcom, infineon, and infineon)
The firmware features and interaction is heavily versioned/compatible over the years.
Without writing 80 pages (only like 3), the easiest mildly incorrect way to think about it is these chips are just arm cores running some firmware, and the driver is reading/writing variables in the core's memory through an interface for variables, and also sending ioctl commands to the cores (getting/setting a variable is actually an ioctl). So there are commands like like "join this ssid" or "here's some roaming preferences". The firmware does stuff with that, and eventually you get wifi packets sent over a ringbuffer. Yay!
You can even, with fun work, gdb the arm cores on the chip, from the host. Or memory dump them, or set tracepoints, or whatever the hell.
Anyway, the firmware on all of these chips, from all vendors, since basically forever, supports the same way to send ioctls and read/write named variables.
They have, over the years, changed which the "current" way to do a thing is. Like for example, they may change the standard way to get the list of available channels, because the old way can't support 6G or whatever. So it will go from "read the chanspecs variable" to "read the chan_info_list" variable. The old way will still often work for years, with whatever limitation exists on it (IE the old way will give you the old format structure, the new way gives you a different structure with whatever new info they added). Sometimes you can combine old things to make new features work, sometimes you have to use the new way.
These days they often change structures rather than commands, and version the structures (enjoy these 12 different versions of btc stats: https://android.googlesource.com/kernel/google-modules/wlan/... or these 6 versions of roaming profiles https://android.googlesource.com/kernel/google-modules/wlan/...)
Kidding aside, this is actually good! It's a sane way to handle this, and i'm glad they started doing it.
What has happened here (most likely) is that the way to set the SAE key in the old drivers became "old and busted", and eventually deprecated by all vendors. It used to be done, shockingly, by setting an variable named "sae_password" in the core (the variables are named with strings). This no longer works.
Nowadays, you are instead supposed to fill in a versioned structure with key type/info and call an IOCTL command (named SET_WSEC_PMK) instead (what gets to be an iovar vs an ioctl vs you name it is ... scattershot)
If you try to set the sae_password variable, on something newer, the firmware will tell you "unsupported". It's nice about it, mind you.
Where does asahi come in:
So Apple's chips have to use the SET_WSEC_PMK path because sae_password is unsupported.
It also turns out that the old sae_password method was being kept around because people thought it worked with the older cypress chips.
But that's exactly what Rachel is saying doesn't work. Hector's patch makes it use the SET_WSEC_PMK in all cases, which i expect fixes it.
If not, you just have to figure out what version structure/command was supposed to be working at the time for this chip. It'll either be an older version of the SET_WSEC_PMK structure, or a slightly different command. THe firmware for some of these chips in this timeframe is actually published as part of the asus gpl sources, so i would bet you can just go tell what it wants you to do to set the WPA3 key.
In that sense, fixing this should be easier than anyone thinks- assuming hector's patch doesn't just fix it, it's almost certainly 1-2 lines of code to make it work if it supports SAE offload.
If the chip doesn't support builtin SAE offload (rare), you can still tell it "i have an external supplicant, please send me the auth frames and such and i'll take care of it". It's not that hard, that is probably like 50-100 lines of code, and very straightforward.
If you want to see exactly what happens, build a kernel with BRCMDEBUG and BRCM log tracing options installed, and then modprobe with debug=1101828 (it's just an of a reasonable set of debug bits)
Then you can watch it boot the arm chips in the wifi chipset, get the firmware console display (the firmware's own logging is read back over the pcie bus), and then you can watch the iovars and commands fly back and forth and what the firmware says to each one.
you will see lots of feature testing and other things. Some things it gets told are unsupported and may try a different way, some it fails, etc.
I am working on better handling the myriad of structure/command/etc versions in the driver (which should have been done years ago), so that eventually it can handle the past few years of chips and structures properly.
They use the same vendor. There are actually a few folks who use the same chips but produce different firmware (was broadcom, infineon, cypress, cypress bought broadcom's IP, and then cypress was later bought by infineon so now it's broadcom, infineon, and infineon)
The firmware features and interaction is heavily versioned/compatible over the years.
Without writing 80 pages (only like 3), the easiest mildly incorrect way to think about it is these chips are just arm cores running some firmware, and the driver is reading/writing variables in the core's memory through an interface for variables, and also sending ioctl commands to the cores (getting/setting a variable is actually an ioctl). So there are commands like like "join this ssid" or "here's some roaming preferences". The firmware does stuff with that, and eventually you get wifi packets sent over a ringbuffer. Yay!
You can even, with fun work, gdb the arm cores on the chip, from the host. Or memory dump them, or set tracepoints, or whatever the hell.
Anyway, the firmware on all of these chips, from all vendors, since basically forever, supports the same way to send ioctls and read/write named variables.
They have, over the years, changed which the "current" way to do a thing is. Like for example, they may change the standard way to get the list of available channels, because the old way can't support 6G or whatever. So it will go from "read the chanspecs variable" to "read the chan_info_list" variable. The old way will still often work for years, with whatever limitation exists on it (IE the old way will give you the old format structure, the new way gives you a different structure with whatever new info they added). Sometimes you can combine old things to make new features work, sometimes you have to use the new way.
These days they often change structures rather than commands, and version the structures (enjoy these 12 different versions of btc stats: https://android.googlesource.com/kernel/google-modules/wlan/... or these 6 versions of roaming profiles https://android.googlesource.com/kernel/google-modules/wlan/...)
Kidding aside, this is actually good! It's a sane way to handle this, and i'm glad they started doing it.
What has happened here (most likely) is that the way to set the SAE key in the old drivers became "old and busted", and eventually deprecated by all vendors. It used to be done, shockingly, by setting an variable named "sae_password" in the core (the variables are named with strings). This no longer works.
Nowadays, you are instead supposed to fill in a versioned structure with key type/info and call an IOCTL command (named SET_WSEC_PMK) instead (what gets to be an iovar vs an ioctl vs you name it is ... scattershot)
If you try to set the sae_password variable, on something newer, the firmware will tell you "unsupported". It's nice about it, mind you.
Where does asahi come in:
So Apple's chips have to use the SET_WSEC_PMK path because sae_password is unsupported.
It also turns out that the old sae_password method was being kept around because people thought it worked with the older cypress chips.
But that's exactly what Rachel is saying doesn't work. Hector's patch makes it use the SET_WSEC_PMK in all cases, which i expect fixes it.
If not, you just have to figure out what version structure/command was supposed to be working at the time for this chip. It'll either be an older version of the SET_WSEC_PMK structure, or a slightly different command. THe firmware for some of these chips in this timeframe is actually published as part of the asus gpl sources, so i would bet you can just go tell what it wants you to do to set the WPA3 key.
In that sense, fixing this should be easier than anyone thinks- assuming hector's patch doesn't just fix it, it's almost certainly 1-2 lines of code to make it work if it supports SAE offload.
If the chip doesn't support builtin SAE offload (rare), you can still tell it "i have an external supplicant, please send me the auth frames and such and i'll take care of it". It's not that hard, that is probably like 50-100 lines of code, and very straightforward.
If you want to see exactly what happens, build a kernel with BRCMDEBUG and BRCM log tracing options installed, and then modprobe with debug=1101828 (it's just an of a reasonable set of debug bits)
Then you can watch it boot the arm chips in the wifi chipset, get the firmware console display (the firmware's own logging is read back over the pcie bus), and then you can watch the iovars and commands fly back and forth and what the firmware says to each one.
you will see lots of feature testing and other things. Some things it gets told are unsupported and may try a different way, some it fails, etc.
I am working on better handling the myriad of structure/command/etc versions in the driver (which should have been done years ago), so that eventually it can handle the past few years of chips and structures properly.
Thanks for writing this up
Of course - i'll add, if someone has an rpi4 around and wants to try it, i'm happy to work with them to fix wpa-3 if this doesn't do it.
I just don't have one to test with.
I just don't have one to test with.
Marcan and their team presumably just gave up and fixed Broadcom/Cypress/Whoever's worthless drivers after being ghosted for months/years by them
Yes.
So is it a Pi problem or not? What did or does Rachel want Pi Ltd to do here? Use a different chipset? Fix the driver themselves, apparently without vendor support?
language question:
"doing us a solid" : idiom?
if so, how does that make sense or what does it refer to?
"doing us a solid" : idiom?
if so, how does that make sense or what does it refer to?
Not a native speaker, but I read this as « a solid favor ».
i am a native speaker, and i've heard it a few times before, and never heard an explanation. your explanation makes sense!
Lots of respect for the asahi project. Soon you can run what is subjectively the best operating system on the objectively best built laptops.
Yes, as soon as NixOS will have native support - I will be buying an apple laptop. The Asahi people are doing a fantastic job.
I doubt it will ever have native support. NixOS doesn't do native support. For what it's worth I'm running NixOS on an M2 Max MPB using https://github.com/tpwrules/nixos-apple-silicon.
Plus one on this repo! It’s a solid experience, I run NixOS on my M2 Macbook Air.
you already have the best operating system on it - the one it came with.
My open-and-acknowledged but not fixed Apple feedback items for very basic issues would disagree with that. (Apple 1st party software crashing on startup, settings search just not working at all, smartcard auth randomly failing, ...)
Until you want to tile 3 windows on the same workspace, which Apple couldn’t fathom someone doing. Meanwhile gnome looks astronomically better with a bit of theming and has nicer animations and window control and resizing behaviour. Must be embarrassing to be even less intuitive than Linux.
> nicer animations
Pointless comment: I can't help but feel that the nicest animations are no animations. I think it's just that each time I see animations I try to imagine what Star Trek would look like if each tap on an LCARS panel took 300ms to do something.
On Gnome if I disable animations and apply https://github.com/bdaase/remove-alt-tab-delay I find the experience to be very good.
Pointless comment: I can't help but feel that the nicest animations are no animations. I think it's just that each time I see animations I try to imagine what Star Trek would look like if each tap on an LCARS panel took 300ms to do something.
On Gnome if I disable animations and apply https://github.com/bdaase/remove-alt-tab-delay I find the experience to be very good.
Why are you comparing default behavior of macOS with Linux after “a bit of theming”. You can easily install a tiling window manager on macOS if that’s your thing.
Installing a tiling WM on macOS (in this case, Yabai) requires disabling system integrity protection. I tried Yabai for a while without disabling SIP (since I can't on my work machine) and it just did not work well. Not the fault of Yabai I'm sure, but there's still a ton of tinkering and tweaking you need to do to get Yabai really working correctly.
I use Yabai on my Macs without SIP enabled. Here’s a list of the features that absolutely require SIP to be disabled: https://github.com/koekeishiya/yabai/issues/1863
But you don’t need to disable SIP just for tiling. I find it works extremely well.
> there's still a ton of tinkering and tweaking you need to do to get Yabai really working correctly
This is pretty much true of basically every tiling window manager on Linux, too.
For me, using Nix-Darwin for MacOS and NixOS has drastically simplified my tiling window manager setup after initially doing the work to figure out my ideal config.
But you don’t need to disable SIP just for tiling. I find it works extremely well.
> there's still a ton of tinkering and tweaking you need to do to get Yabai really working correctly
This is pretty much true of basically every tiling window manager on Linux, too.
For me, using Nix-Darwin for MacOS and NixOS has drastically simplified my tiling window manager setup after initially doing the work to figure out my ideal config.
Does Linux have System Integrity Protection?
I don’t mean a window manager, I mean just snapping 3 windows together is impossible on macOS. Theming doesn’t change that.
I've not had issues with WPA3 on my tame Raspberry Pi 3B and 4B critters. So I'm confused as to why there are issues ?
Here's the original article https://rachelbythebay.com/w/2022/12/22/wpa3/
> By "true WPA3", I mean a network that's only speaking WPA3 in SAE mode, which requires protected management frames (802.11w), and which does not support any kind of WPA2 fallback. This is a network that you can scan with something like Kismet and it'll say "WPA3-SAE" and nothing else. A stock RPi will absolutely fail to connect to them. This has been known for years and yet still persists
> By "true WPA3", I mean a network that's only speaking WPA3 in SAE mode, which requires protected management frames (802.11w), and which does not support any kind of WPA2 fallback. This is a network that you can scan with something like Kismet and it'll say "WPA3-SAE" and nothing else. A stock RPi will absolutely fail to connect to them. This has been known for years and yet still persists
I see, that's interesting. I do run a mixed WPA2 and WPA3 WiFi network, that would explain why they were happy.
Is there anything I can input in the terminal to confirm the type of WPA in use?
Is there anything I can input in the terminal to confirm the type of WPA in use?
This is (bit of a callback) exactly the sort of story I would like the new journalist at lwn.net to deep dive in, give us a nuanced, sympathetic story of what really happened and how such decisions are made.
No blame - just good decisions. it's what we want all over