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?
> 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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, ...)
This is oddly something about social proof - the upstream maintainer did not want to break cypress support but needed a high profile public confirmation that the cypress code was not working (presumably as a final straw that broke the camels back)
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
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.
> 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
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?
If you’re designing a board specifically for mass-market linux support, “pick hardare with good linux support, or work on it yourself” doesn’t seem like too much of a stretch?
> 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.
46 comments
[ 3.6 ms ] story [ 99.4 ms ] thread> 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.
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...
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 figur...
I just don't have one to test with.
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.
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.
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
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.
Some of us live in a different RPi 5 availability world apparently.
Still no love for WPA3 on the Raspberry Pi 5 - https://news.ycombinator.com/item?id=38170980 - Nov 2023 (155 comments)
> 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
Is there anything I can input in the terminal to confirm the type of WPA in use?
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.
Very kewl! What era did you use Solaris x86 in, and for what reason?
"doing us a solid" : idiom?
if so, how does that make sense or what does it refer to?