Still no love for WPA3 on the Raspberry Pi 5
rachelbythebay.com
rachelbythebay.com
With the Compute Module 4, I've successfully tested a variety of adapters [1], from WiFi 6E to older mini PCIe and M.2 cards. There's even a board made for the purpose of multi-WiFi testing, the Seaberry [2].
The Raspberry Pi 5 works with all the PCIe WiFi chips I've tested (haven't had time to summarize testing on pipci database site yet), including a mt7921u-based WiFi 6E USB adapter (haven't written that up, but check out [3]).
[1] https://pipci.jeffgeerling.com/#network-cards-nics-and-wifi-...
[2] https://pipci.jeffgeerling.com/boards_cm/seaberry.html
[3] https://github.com/morrownr/USB-WiFi/issues/137#issuecomment...
But after buying one or two of every Alfa usb cards out there with all the different chipsets, I found each chipset would have some horrible blocker. Some examples, iirc (it's been a while): Realtek-based AWUS036H would work some then die & throw a bunch of kernel messages. Atheros-based AWUS036NHA was working great, but was limited to ~8 clients.
I keep hoping someday the RPI can make an actual respectable decent AP, without needing to go for a pcie carrier board (and frankly, it seems like there's not good availability for AP grade PCIe cards either... everything seems to be rebadged Compex cards, usually at astronomical prices). I keep hoping wireless can be more DIYable in general.
The Morrownr/usb-wifi repo has been such a godsend. There's just been no stable repository of knowledge for so long. But I haven't dared wade back in, & figure out how I'm going to be disappointed this time around.
The codepath the driver uses to set the password does not work on newer firmware, and hector fixed it to use the new way.
If that fails I have a patch that lets it use an external supplicant for WPA3 when it it truly unsupported by the chip (which is rare)
The driver is unfortunately not kept up to date - this stuff should have been added (along with other things) years ago.
Edit: Actually looks like hector just sent it in response to this blog post. Should show up in the kernel archives soon if you want to try it
Infineon fixed it in their driver patches as well, at least a year ago. They just don't upstream them (though they are in github)
In some ways this actually sucks more - because everyone is spending time rediscovering the same issues and fixing them.
Also, Rachel is i think wrong on one thing - i believe this chipset was used as far back as RPI3B+
(or so various sources seem to say)
Which is even worse.
Sadly the biggest volume of Internet of Shite devices are going to be quickly every Windoze 10 system out there that Microsoft refuses to support WPA3 despite drivers, stating only Win11 would get it. Another reason for them to push people their new Telemetry spyware with improved even less privacy.
Oddly I purchased a Zyxel Wifi 6E AP with 6ghz, and it does let me operate in WPA3 and/or WPA3-Transition while letting things connect to 6ghz or 2.4/5ghz, which Cisco/Meraki simply does not allow, and from my understanding correct per spec. I just have to wonder if those wacky Asian semi's are purposely ignoring that spec or simply blissfully ignorant of the fact it's not exactly adhering to rules.
Either way I was annoyed with Cisco by it and recommended next time they spend less and get non-Cisco kit that were more flexible, recommending Zyxel for a literal 10th of retail cost of the same Cisco AP.
It’s a 10th of the cost for probably 10000th of the R&D budget alone. Zyxel devices, especially the firmware are a total joke. It’s consumer grade garbage sold with quasicommercial marketing. And you use this equipment in a security sensitive environment at your own peril.
Windows 10 seems to support WPA3.
https://support.microsoft.com/en-us/windows/faster-and-more-...
There's no technical reason that windoze 10 should NOT support it far as I know, they're simply using it as a reason to push people to 11. I can and have added a 6ghz usb nic to a 10 dollar and 10+ year old netgear router and have it work, there's no reason windoze 10 can not other than Microsoft says no.
I wouldn't be surprised if this is Intel shenanigans because they have always segmented their OS driver support dating back to Windows 7. Anything from laptop gpu drivers not getting updates after 2 years to chipsets suddenly failing the compatibility mode flags on newer windows that has never changed since older windows. Intel just literally doesn't care. They shovel their crap out.
If you do WiFi 6E you have to do WAP3 (SAE) and there is no backward compatibility to WPA2. You can do transition mode but only in 2.4/5Ghz bands, not 6Ghz band.
WiFi support is kind of a mess of nasty blobs across the board unless you go back to Wireless AC or N, though. I have been wanting an AC option that works with linux-libre on Guix System. I once bought a RealTek USB WLAN adapter after seeing what looked like a firmware repo with a free software license, but apparently it wasn't the actual source, just a binary, so still needed reverse-engineering work. I just chucked it in a drawer for now and only use ethernet on the laptop I'd intended it for.
It would be cool to see a group effort to find the most common WiFi chips used in devices and work on REing them. Liberate as many devices at once as possible.
It's that ISM has power limits, and most radio freqs also has "minimum power to accomplish communication".
And the FCC knows in contentious RF environments, loudness wars would inevitably happen, as we saw in CB during the 1970s. And in 5.8GHz, wifi is a secondary priority to radar scanning applications. Again, human operators know this.
The FCC is being a good steward in preventing the downward slope of the tragedy of the commons. And, well, that's their mission.
We can't trust non-licensed human operators to not take the volume to 11, and TX when they shouldn't. Id rather have hardware blobs that enforce FCC law than locked down devices.
But then, wouldn't it be better to have the power limit baked into hardware instead of it being just a software limitation? Sure, this would add a little more burden to hw manufacturers. But not only would it allow for open firmwares, it would also be better at preventing the scenario the FCC is worrying about: with the limit being in software, with some effort someone could still reverse engineer the blob and disable the limit.
A good middle ground would be to have two blobs, one for low level radio control and one for everything else. The low level radio blob can be locked down so that only blobs signed by the manufacturer can be loaded. The everything else blob can be easily replaceable.
I've observed that people with the bare-minimum knowledge to access the admin interface love going in and just cranking up every single number (that they don't understand) to "11". Bigger is always better, right?
This is why you see people doing umm, "questionable" things like configuring 40 MHz 2.4 and cranking the power to the max even in dense urban environments. Needless to say that configuration alone results in a complete mess for everyone in range of these configurations.
Unfortunately the vast majority of people don't understand any of these parameters (which is fair) and I, for one, am glad there is some nannying going on. I can only imagine how much worse it would get if more parameters were exposed. You'd very quickly see manufacturers essentially get into an even worse "loudness war", or readily available firmwares with nightmare configurations that make it easier for people who don't know what they're doing to make a complete mess of things for their neighbors (and themselves).
We all share this spectrum and people, when given the ability, will often do things that adversely impact all of us.
This is why Ham Radio has bare-minimum licensing requirements and some enforcement. That spectrum is shared as well and combined with higher ERP it would turn into a complete mess very quickly.
Unfortunately because of the tragedy of the commons those of us who do know what we are doing are hamstrung as a result.
https://www.eff.org/deeplinks/2016/08/fcc-settlement-require...
Better news! Rockchip, by default, ships broadcom's bcmdhd driver, with a few hacks for linux, instead of making brcmfmac work.
See here: https://gitlab.com/rk3588_linux/rk/kernel/-/tree/develop-6.1...
This is a great driver, which, if you insmod it and rmmod it, will 90% crash your kernel.
But, if you don't look at it too wrong, it will mostly work.
To be fair: DHD is mostly used on Android, and there Google/Broadcom have spent a lot of time making it work well.
>90% of people don’t use WPA3. And a huge part of those that do (including myself) have networks with automatic WPA2 fallback even though that neutralizes most benefits.
Maybe in 5 years it will be different. In my opinion though, it won’t matter until the day that one ISP somewhere ships a WPA3-exclusive router, which isn’t happening soon.
Though the difference here is that was common infrastructure managed by large companies.
No reason a home router won’t stick around a lot longer. A non trivial number of people still have land lines with rotary phones!
Maybe. Maybe less. Worth worrying about if you're doing a hardware project that's going to be around for a while.
> Though the difference here is that was common infrastructure managed by large companies.
> No reason a home router won’t stick around a lot longer.
A lot of the time people's home router is tied to their ISP and they have to change it when they switch or move.
> A non trivial number of people still have land lines with rotary phones!
Really? My parents had to replace theirs ~5 years ago when the phone company stopped allowing pulse dialing.
Are they still on POTS, or a voip bridge? Most POTS providers still support it, but most voip bridges don’t.
My mother however does not care (as an example). At the same time she and most other not so tech savy people aren't using a Raspberry PI.
I think the demand is there.
It's impossible to get compliant WPA3 working on said device because the final firmware blob for the radio has a broken PMF (802.11w) implementation.
The entire Marvell wifi/bluetooth portfolio was later sold off to NXP, whom presumably aren't helping either as the issue remains.
Most of the other vendors seem at least willing to engage, from what I can see skimming through linux-firmware.git
More useful would be knowing what combination of kit (linux router/AP as well as device) gets me robust high speed.
(I was feigning a bit of ignorance, I'm a bit of a minor crypto nerd.)
OK, cool, so WPA3 has PFS.
But so does wireguard.
When I opine "what's really the _point_ of WPA3? (and wpa2!) I'm mentally comparing it to _no_ encryption at layer 1 (aka open network), but with performant (and arguably more secure) encryption at layer 3.
I have given up using built-in Bluetooth and Wifi at the same time years ago, when they were interfering with each other. Nevertheless, I wonder if that is still the case.
I used to work support for an ISP and we would always get customers calling up complaining that our wifi router was shit, but it almost always turned out to be some weird unshielded device causing electrical interference (I remember we would always get a glut of these calls around December when people plugged their cheap Christmas tree lights in!).
Our family home has a strangely cursed wifi, after changing 4 routers it seems to have stabilised, but I still dont know why
Nevertheless, I have done countless hours of troubleshooting and investigations, and not looking for more anymore. RPis are great for many things, and pretty crappy for many other things. I found their wireless capabilities to be on the crappier side.
Here are my unrequested 2 cents: if this solves the issue, have a systemd (or cron) timer do that for you. Sure it's duck tape, but it would make it way less painful than having to do it manually each week.
I'd be happy to run on arm or riscv if I can get high throughput and can expect Linux kernel support for a decade or so.
If you don't want wifi6 or 5ghz support, it's easier.
(not affiliated, don't work for intel, have a bunch of other cards, most were a pain).
I don't know much about it but things like DBDC/MIMO are probably wanted. Other people may be able to comment more about this though.
I just went down the route of using a Banana Pi R3 with OpenWRT in the end though[2]. The R4 does exist now with Wifi 7 though[3].
[1] https://asiarf.com/product-category/wi-fi/wi-fi-module/wi-fi... [2] https://wiki.banana-pi.org/Banana_Pi_BPI-R3 [3] https://wiki.banana-pi.org/Banana_Pi_BPI-R4
I just recently got a raspi 5 and the wifi chip is flaky. I can't help but wonder if they're fighting the edge of the board's thermal load and a chip supporting WPA3 would be too much.
All it takes to fix it is for Broadcom to get serious about their software support.
Furthermore there is the problem of radio interference. I wired all my Raspberry and equivalent devices. One of them runs tvheadend to stream the TV signal I get from the antenna on the roof. I had freezes in the stream to my phone and tablet and they went away after I connected that RPi3 with an Ethernet cable. I think that the packets of the stream and the ACKs at TCP and possibly at application level (I don't know which protocol it uses, VLC handles it) were interfering and one of the devices had to stop transmitting from time to time.
That being said, a flagship system should have future-looking support.
The state of the embedded industry continues to amaze me.
The RPi really does suck from a professional use-case: no volume, no 10 year guarantee, no proper industrial certifications and until a few years ago, extremely bad integration with tools like Yocto.
The two segments do overlap sometimes, but it's definitely not the same beast. A lot of SBC vendors have provided great boards over the years (looking at Variscite, PHYTEC, Toradex, SECO et al), but the incentives, and thus the final product, are not what hobbyists expect.
I've played with it some but I'm no professional here. I personally do consider it a major contender thanks to OSD335x SiP modules (although I haven't built an OSD335x, the deadbug demo intrigues me: https://octavosystems.com/2019/04/12/osd335x-c-sip-dead-bug/).
https://www.digikey.com/en/products/detail/texas-instruments...
The AM335x is clearly still a common chip today.
-------
Mouser also has 3000, 4000, 5000 in stock depending on SKU ( AM3357BZCZA80 vs AM3352BZCZA80). Easily 15,000+ at Mouser if you're not picky about the particular part in the series.
I think this is why the am335x and imx6 are still available, despite the am335x being older than the Raspberry Pi 1.
Of course, such chips are generally slower than flagship phone/tablet processors even at launch, and after 10-15 years even moreso.
That being said I wouldn't recommend shipping an OMAP product in this day and age. Something with a MediaTek SOC is probably more palatable if you plan to spin up production at volume.
Oh, I see the confusion now. I didn't realize that Beagleboard was OMAP old.
I was talking about Beaglebone Black/Green, which is a 10-year-old design yes, but the AM335x line of Ti chips (while a decade old) seems well supported and working with mainline Linux.
Beaglebone Black/Green seems to be comparable to Rasp. Pi 1 or Rasp. Pi 2, though with far less power consumption, better documentation. I'm impressed by it, though I haven't made the leap into a custom design yet.
-----------
But yeah, I guess I only became aware of Beaglebone around Beaglebone Black era / Sitara line. I always saw them as the "Industrial Rasp. Pi" if I wanted to reach for a more serious project, though I haven't really done any good electronics work back then. I'm doing a bit more of an electronics push these days again though.
I'm more interested in Beaglebone Black / Green because AM335x has 0.80mm pin pitch BGAs, which looks doable on OSHPark 6-layer 5mil trace/space.
More recent Beaglebone Play / AM625 has far superior specs (quadcore + CortexM4 onboard / etc. etc.), but 0.5mm trace is literally impossible at 5mil trace/space.
If you can get away with something low spec then you'll be fine, generally. Board bringup for any Cortex A8 or similar is comically easier than for lines ending in double digits.
I found Rockchip much easier to work with than TI, fwiw.
Because of better support from TI, BB always had a more professional feel than the Raspberry Pi, specially for documentation etc. It's a fine chip, if you can source it (haven't messed with anything from Octavo, but it seems solid to me). All the software issues are pretty much solved and upstreamed at this point.
I think the main advantage, for my hobbyist self at least, is the 0.80mm pitch BGA which is doable on OSHPark.
TI's more recent AM625 is 0.50mm pitch, which is too small for OSHPark 5mil trace/space, lol. Perhaps a bad reason to a professional but... I'm filtering out for chips that I can actually affordably make a PCB for on a hobbyist scale.
Old does not mean worse.
All of the extra gorp on newer chips takes a LOT more power.
For example, that 10-year-old chip runs Linux quite reliably in a 5V-500mA power envelope--something the RPI series never did.
And I mean, it works! But it's an unsafe mess which generates a bunch of regulatory issues and it keeps me up at night :-)
Spot on. Rpi actually suck if you compare it to industrial automation PLCs eco-system, heck, even compared to other SBC like nvidia jetson.
Wait, what? PLC’s and Raspberry PI’s have nothing in common surely? PLC as in thousands of dollars, Ladder logic, built like a tank and about the same size? When has a PI ever been compared to a PLC?
> which usually is what "industry" is being referred to.
Bingo. It's always a bit hard for me to properly communicate to people that the 'industry' is not an air monitoring/grafana-prometheus/PiHole/whatever low-volume, no risk application.
I'm not affiliated with this, just poked around. Looks neat by the way.
https://github.com/agherzan/meta-raspberrypi
For what it's worth, the entire Pi lineup is also well supported by Buildroot. In-tree, no less.
It takes a serious effort and money to maintain a layer. It's not easy to integrate and test everything.
You cannot iterate quickly based on the glacial embedded industry. I am amazed by the way we are quoted 3 month wait for a shipment (even pre-covid) without anyone batting an eyelid.
You're a bit like the satellite industry looking at Starlink and saying "well it's not true satellite, doesn't have X, Y and Z" and pointing to a few specialist applications where legacy satellite is highly suited and ignoring the masses of business applications that have moved to Starlink.
My only fear is that, it's really, really hard to get a safe, performant product without really knowing what you're doing. And although RPi and others do a good job at the prototyping level, it becomes messy very quick.
We're trying to be better, though, there are some nice solutions popping up here and there.
Korg makes a line of popular synthesizers that are based on RPi, so I believe the volume issue has been solved?
https://www.raspberrypi.com/success-stories/korg-synthesizer...
It would allow you to do network reliability testing, as well as get data back on Wifi AP's and some environmental data.
Company I worked for had them spread out across all of their offices in various different locations, all of them reporting back to a central location.
When we took apart the device we found a Raspberry Pi inside, with a PoE hat. It made sense for the use case, cheap devices, custom case, and MAC address that was set to the vendors MAC address range upon boot up.
At the time I was helping with a security assessment, and being able to run our own software/tools on a device that would blend in was kinda nice ;-)
"Embedded industry" is a VERY large segment.
Here's a fun one for you. This was told to me by the person who helped build this project. Parallax makes a device they call the BASIC Stamp 2 (https://www.parallax.com/product/basic-stamp-2-microcontroll...). It is a very easy to use and develop for microcontroller yet it is incredibly capable. You program it in BASIC.
The BASIC Stamp 2 was for the longest time used in a production sold to consumer timer clocks for turning solenoids on and off for sprinkler systems. At one point in time you could buy it off the shelf at Home Depot not knowing that the device contained a very simple BASIC Stamp 2 to do its functions.
These devices end up in the weirdest places. You'd think a manufacturer would switch from a BASIC Stamp based product to spinning their own board + using a small embedded CPU instead, but the cost savings just weren't there.
The RaspberryPi is likely used in far more places than you or I could imagine in ways that are considered "professional". That stuff gets hidden in little metal/plastic moulded boxes and for all intents and purposes disappears.
Is that really a feature? Having to use a mess of vendor kernels and overlays that patch anything from ffmpeg to GTK to chromium just to build a 5 year old, EOL kernel version that still doesn't do what the board was advertised as supporting.
E.g does a SBC really support accelerated video decoding if it's only via patched libraries that are also 3 years old?
IMO the embedded Linux ecosystem seems to really hate Linux since it rarely follows standards (especially in user space) or upstream drivers, etc.
In one of the Yocto Summits I've been to there was literally a talk about "stop venturing the kernel". Everyone hates it. We really do fight against the major SoC vendors to stop not upstreaming stuff and it has been getting better :-)
> and until a few years ago, extremely bad integration with tools like Yocto.
WEP was garbage because it could be cracked in minutes on a laptop. WPA3 is mostly a WPA2 revision that mitigates very expensive attacks.
Already I have run across a plethora of devices that do not connect to networks in WPA2/WPA3 mix mode. Consumers who are not technically literate will return new hardware they buy that doesn't connect to their WPA3 enabled Wi-Fi network. Their iPhone and laptop connect to it without issue, thus it must be a defective device if your IoT thing won't connect to the existing WPA3 network.
I appreciate the sentiment, but new devices being sold that still don’t support WPA3 means the adoption of 6GHz is going to be a very slow process.
More info here since this is surprising to many: https://www.extremenetworks.com/resources/blogs/wireless-sec...
Sounds to me like if something doesn't support WPA3, it also doesn't support 6GHz which makes the point moot.
No, it just means the adoption of WPA3 is going to happen at the same speed of 6 Ghz. The point is that every device that supports 6Ghz has to support WPA3.It's not like you could do 6Ghz on your Raspberry Pi but lack of WPA3 blocks you from it.
It would be like if USB-C required any device with USB C to not support any other USB types or specs. Seriously, what the hell!
And no, there is no practical reason for them to be mutually exclusive.
For Wi-Fi to survive, it must bring improvements in security protocols /and/ user experience (speed, coverage, and ease of setup). While I agree that security configuration should ideally not be tied to the physical characteristics of the link, security tends to lag, and the driver is user experience. So, if we want to have a high baseline of security, we have to tie it to the driver, the craving for a better user experience (higher speed and better spectrum utilization).
Good standards make trade-offs in the right places (both in time and space). Dumb standards miss the goal. I cannot say that this is a dumb standard when it is evident that trade-offs have to be made. Using WPA2 would have impacted cost of equipment, performance and security negatively.
As I said, dumb.
Next version will likely include degrees of backward compatibility or workarounds, would be my guess. Since you can’t even iteratively roll it out!
That or routers will have parallel radios and 2x SSIDs, which would confuse everyone and add even more to the costs.
Yay for IPv4 vs IPv6 on wifi.
If this is about 12.12.2, then it refers exclusively to the 6GHz STA, and not "to the entire network", which on Wi-Fi is a very loosely defined concept (same BSS? same ESS? already the standard forces different channels to use different BSSIDs).
Nothing prevents the 6 GHz AP's SSID from "coincidentally" being the same as the 2.5/5GHz AP. In fact, this is exactly how a/n works now: even though initially it was common for 5GHz STAs to operate on a different SSID, no one bothers to check, and nowadays I can barely find a consumer/business AP that _by default_ still keeps separate SSIDs for both 2.5 and 5.
While I can find APs that today by default give different SSIDs to 2.5/5 and 6 (oh, the irony), I have not found any that would prevent me from setting the same SSID to all; and some APs I have already set the same SSID to 2.5/5/6 by default. These all have the Wi-Fi logo.
> You can’t band steer 6GHz clients to a preferred 6GHz compatible WPA3 only network, it’s up to the user to pick the right SSID.
You have never been able to truly band steer clients since this is at the client's discretion. Even if you give everything the same SSID, the client may choose to prefer the 2.4GHz band instead -- this is also one of the reasons it was common to give both of them a different SSID early on, so that users could force 5GHz.
When commercial routers "band steer" they simply prevent the client from associating to to the lower bands (by e.g. hackishly not responding to probes at that band), thereby leaving the client with only one choice: the band you want.
I can understand a desire to kill WPA2 (and I can make some guesses about some maybe less noble motives)... but the WiFi standards can't effectively mandate things the market won't accept. Little trademarked "certified" logos and whatnot end up losing out to "it actually works". Generating pain in the process.
WPA2 is susceptible to offline-dictionary attack and the cost is quite low (less than $10), especially with cloud computing. WPA3 is resistant to offline dictionary attack.
If an adversary knows the WPA2 passphrase, the adversary can eavesdrop on connections between the AP device and the station device. In comparison, in WPA3, even if an adversary knows the passphrase, the adversary will not be able to decrypt communications between the AP and the station device. The adversary is still able to gain access to the network, but the attack surface area has been reduced.
WPA3 uses HMAC-SHA256 for key derivation, whereas WPA2 uses HMAC-SHA1. NIST and other cryptography agencies have recommended against the use of SHA1 in cryptographic systems due to known weaknesses.
WPA3 has many advantages over WPA2. In addition, most of the implementation for WPA3 is in software and also available as open source.
AFAIK SHA1 is only broken with respect to preimage/collision attacks. For generating random bits it's still perfectly fine. In other words, sha1 is broken, but not in ways that matter for its use in WPA2.
I agree that offline attacks are a threat to WPA2, but do you have a cost breakdown/source/? for that cost figure? The attack to me is still in the realm of unlikely if not using a common, rainbow-tabled SSID and/or very simple password.
I am not involved in the GPU cloud compute area, so I only did a very quick check on EC2 GPU instance pricing. At about 10$ that translates to about 2 hours of g5.12xlarge with 4 high end GPUs. I am not familiar with these models, but I am assuming they are comparable to high end, current gen GPUs. To me 8 GPU hours sounds a bit on the low side, even for relatively weak passwords. For reference, it seems an RTX 3090 does about 1 MH/s [1]. 8 GPU hours on that card translates roughly to 230 billion (230x10^9) password variants, a lot, but not overwhelmingly a lot. An 8 character lower+upper+digit is estimated at about 47 bits, so roughly 140x10^12. A wordlist+mutation is likely far more efficient than a naive attack. I am on the fence whether this makes for a reasonable 10$ real world attack.
Happy to learn I am stuck in the past!
(The rainbow table I am talking about: https://www.renderlab.net/projects/WPA-tables/)
[1] https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...
(EDIT: * -> x, one day I will learn formatting)
Only if it's a common password... you're saying this like it's a given, like you can break into anyone's WiFi for less than $10 after capturing a correct authentication challenge+response from a legitimate user.
If you have a stupid ISP in the area that uses crackable passwords, or tech-savvy users that change the password to something stupid, perhaps you'll have a decent recovery rate, but otherwise I'd estimate it's far below even odds whether this gets you into any given network.
Putting a dollar price on cracking a hash is like putting a dollar price on fresh air: if you have a laptop standing around, it's practically free to try a few million passwords; if you need a GPU farm, it may cost ten thousand euros; and it may be impossible if it's just not crackable (27 chars alphanumeric is just not possible, also not with a quantum computer in a thousand years, but you don't know that when all you've got is the challenge-response hash).
And still boots with a bespoke, incompatible and awful boot process, instead of standard ARM SystemReady.
And still uses legacy ISA (ARM) instead of open standard RISC-V.
They lived up to that goal 10 years ago.
But there are "stated goals" and "actions", and actions speak the truth when they're in conflict with stated goals.
The recent (lack of) availability to anyone except commercial/industrial buyers. The Pi Foundation hasn't demonstrated any success getting affordable computers into the hands of anyone except high volume commercial buyers in the last few years. They're riding on their "hobbyist" reputation and taking advantage of everything hobbyists (and educators and open sourer developers) have done for their product, while turning their backs on all those people.
Why would any open source dev bother fixing their Wi-Fi drivers for them, when they won't even sell you their board to test on reliably?
While Pis were a hot commodity about a year ago, today as far as I can tell consumer Pi supply is mostly back to normal. My local vendor has stock of 0s and 0Ws, 02Ws, every memory config of 4B other than the 1GB, 3As, picos in all configs, and some flavors of CM4. Yes, 5s are somewhat hard to get, but I don’t think it’s big institutional customers soaking those up - there isn’t a CM form factor for them yet, and besides, nobody would have had time to build a full product around them yet.
The correct decision would in my opinion have been: prioritize the business customers as the Raspberry Pi Foundation did (exactly because of such a reason), but let them pay grossly inflated prizes for this privilege, which hardly any private customer would be willing to pay.
If such a course of action had been done, hardly any hobbyist would have complained, in particular or for example if such "exploitative" prizes for business customers would have been used to subsidize Raspberry Pis for schools during the pandemic (which was the original mission of the Raspberry Pi Foundation).
The fastest RISC-V core available is nowhere near ARM chip speeds; the core itself is proprietary; the drivers can easily still be proprietary because RISC-V says nothing about open-source drivers or boot toolchains; and it would probably be more expensive like all bespoke technology is.