[HN Gopher] Asahi Linux folks are doing us a solid with WPA3 fixes
___________________________________________________________________
Asahi Linux folks are doing us a solid with WPA3 fixes
Author : picture
Score : 86 points
Date : 2023-11-07 21:49 UTC (1 hours ago)
(HTM) web link (rachelbythebay.com)
(TXT) w3m dump (rachelbythebay.com)
| yjftsjthsd-h wrote:
| 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?
| IntelMiner wrote:
| Marcan and their team presumably just gave up and fixed
| Broadcom/Cypress/Whoever's worthless drivers after being
| ghosted for months/years by them
| ZiiS wrote:
| Yes.
| Wowfunhappy wrote:
| 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.
| mcbridematt wrote:
| The Cypress chipset used to be a Broadcom product. Broadcom
| decided to sell the 'IoT' side of their WiFi/BT product line.
| mcpherrinm wrote:
| 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...
| jacquesm wrote:
| 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.
| DannyBee wrote:
| 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.
| pavon wrote:
| Nitpick: Cypress was bought by Infineon
| DannyBee wrote:
| Whoops, yes, sorry
| justahuman74 wrote:
| Thanks for writing this up
| alphanullmeric wrote:
| Lots of respect for the asahi project. Soon you can run what is
| subjectively the best operating system on the objectively best
| built laptops.
| mateuszf wrote:
| Yes, as soon as NixOS will have native support - I will be
| buying an apple laptop. The Asahi people are doing a fantastic
| job.
| _zoltan_ wrote:
| you already have the best operating system on it - the one it
| came with.
| alphanullmeric wrote:
| 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.
| herrkanin wrote:
| 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.
| alphanullmeric wrote:
| I don't mean a window manager, I mean just snapping 3
| windows together is impossible on macOS. Theming doesn't
| change that.
| bs7280 wrote:
| Check out Yabai WM if you still have a macOS laptop
| Krssst wrote:
| > 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.
| lifeisstillgood wrote:
| 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
| musicale wrote:
| > 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.
| dang wrote:
| Recent and related:
|
| _Still no love for WPA3 on the Raspberry Pi 5_ -
| https://news.ycombinator.com/item?id=38170980 - Nov 2023 (155
| comments)
| mrlonglong wrote:
| 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 ?
___________________________________________________________________
(page generated 2023-11-07 23:00 UTC)