Just a note that if you're _serious_ about WiFi on the Raspberry Pi... you should use an external WiFi adapter—either PCIe or USB. (Mentioned in the article, but in general, the WiFi chips built into SBCs of all varieties... aren't great.)
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]).
I'm curious how well AP mode works for usb cards these days. After a bunch of years with Openwrt (mostly on a bunch of netgear wgt634u's), I was pretty gung ho about trying to switch off router hardware and to more generic-computer + wifi for wireless infrastrcuture. Ideally if I could via usb cards, as those were so easy to add to even small systems like the early rpis or cheap chromeboxes.
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.
Pretty much yeah, RPi have their own use (like any SBC) and I like them to power a drone or UGV, but to use it as an AP/Router is kinda silly and overpriced, and it’s buggy too.
Asahi Linux is one of the most exciting Linux projects in years. That team is world class and helping all of us while also prying open Apple's walled garden.
This is going to be a more common problem with 6ghz radios and Wifi 6E/7 requiring WPA3, and no transition mode permissible per spec. I recently ran into this with a customer running Cisco Meraki AP's that it was either disable 6ghz to keep legacy devices working with wpa2-psk, which was a lot of random things including laptops with old nics, Ring doorbells, various old mobiles, etc, or replace them with not crappy/old wifi devices. We had to push all the crap like that to the guest network vs. an enterprise ssid we actually wanted to use the 6ghz with for performance.
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.
> 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.
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.
Microsoft isn't in charge of this though. It's the wifi card vendors.
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.
> 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.
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.
> 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.
The Raspberry Pi using Broadcom chips has always made it hard to take seriously. How are competing boards with RockChip SoCs doing on this front?
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.
The FCC doesn't want people modifying their routers such that they use more power than they are allowed to. This results in end users being unable to modify the firmware that controls the radios.
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.
The logical conclusion of this comment can be seen in my laptop: a wifi chip that is locked to the "global" regulatory region (the worst possible frequencies and output available) because I cannot be trusted to tell in which country I am.
> 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.
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.
> 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.
Manufactures like to do it in firmware because then they can use the same hardware worldwide. If they find sales are higher than forecast in Europe say, and lower than forecast in the US they can just flash more units at the factory with EU firmware and less with US firmware.
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’m not sold on this being an issue. Maybe by the Pi 6 or Pi 7 it will matter.
>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.
You are right that most places I know about turn off 3G instead of 2G, mostly because of embedded users relying on 2G. Switzerland on the other hand decided to turn off 2G while keeping 3G running (for now): https://www.comcom.admin.ch/comcom/en/Homepage/documentation...
Prusa i3 MK4s networking is so bad, it struggles to get up to 1Mbit with the currently implemented security protocols. I just use Ethernet with mine, it's just as bad performance-wise but at least it doesn't communicate wirelessly using insecure protocols.
WPA3 provides among other things perfect forward secrecy. If your WPA2 password becomes available to a passive attacker that has listened in for the entire communication including the handshake, they will now be able to decrypt. Or in other words, any person who gets your wifi password can (passively) listen on traffic in your network. WPA3 requires attacks to be active with a proper man in the middle (less easy to do that in a wireless setting and also only applies to the future).
(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.
Not all people are (self proclaimed) "crypto nerds" who have Wireguard-based VPN running on all their wireless devices at all times. I would venture a guess that absolute majority of people don't.
I sencond this, better to implement encryption at the lower layers, so that people get protected regardless of how the upper layers are built/configured.
WPA3 is definitely not as secure as wireguard, but it's a pretty good improvement compared to WPA2. 99% of people just use the defaults of their WiFi deployment, and then have stuff like network printers or NAS on there, with varying levels of encryption. Thankfully due to https being so widespread, most of the traffic to the public net is encrypted now. But even now you can find out which websites someone visited by looking at DNS and also the ip addresses of the packet headers.
Personally I would be happy with any kind of stable wireless support, even the most unsecure or obsolete one. My Pi3 and Pi4 both can't maintain stable wifi connection for more than a week. After that they simply become unresponsive on the network - I got to unload and reload the driver to make them communicate through the network. I solved this on one of them by simply connecting though ethernet, but the other one is still a constant pain.
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 have six Raspberry Pi's (from the Pi Zero W all the way to the Pi 4) plus several other wifi microcontrollers (ESP8266, ESP32, Pico W etc) doing things around my home and they all happily sit on my wireless network without an issue. Is it possible that your home is subject to some kind of interference that they are struggling to cope with?
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!).
I have many other devices also on the same network: 2 iPads 24/7, Mac Mini 24/7, 2 Linux laptops running at least 16h/day, smartphones, PS3, PS4, etc etc... in a small apartment. I'm a city dweller, wifi routers trying to scream over each other, there are like 50 networks visible where I sit. But: if there is some interference, I would expect at least some other devices to expose the same behavior, at least occasionally. But exclusively only the Rpis are doing this - after 4-10 days of uptime, they just give up on the wireless network, without any error message or any other clue.
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.
> I got to unload and reload the driver to make them communicate through the network
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've been trying to figure out if there are any hw out there that allows good wifi6/hostap support under Linux, to run an access point - the nearest I've come is this[1] list. But I'm still unsure if it is feasible to build an access point on top of an Intel/AMD minipc with contemporary hw?
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.
Yes, see https://github.com/morrownr/USB-WiFi/ for an overview. Despite being hosted on GitHub and having an issue tracker, it is a documentation-only project, not software.
Have you had a look at AsiaRF[1]? If you are building an access point you are probably looking for more specific cards. You do miss out on things like hardware offloading if you go down that route afaik though but it may not matter due to the extra processing power you tend to get.
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].
I can't help but wonder if thermal load is an issue.
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.
Nope. It's just a matter of poorly maintained brcmfmac driver in mainline Linux. It gets barely any attention from companies that produce the hardware it supports.
All it takes to fix it is for Broadcom to get serious about their software support.
Is WPA3 ubiquitous? I have yet to see a WPA3 network and I don't see myself switching to 6Ghz at home while I am better off using 2.4Ghz than 5Ghz due to thick walls and lack of power outlets.
Exactly my thoughts. I'm using 2.4 GHz and sometimes I lose signal when there is a think wall or a floor between my phone and the access point, especially when the wall is at a small angle and the signal has to pierce many meters of bricks.
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.
The incredible part is the RPi sucks less than all the other commercial embedded SBCs such that it's had huge industry uptake purely by being the least worst.
The state of the embedded industry continues to amaze me.
I think you're confusing 'embedded industry' with 'embedded hobbyists', because we (the industry) don't focus on hobbyists.
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.
Exactly as you see in this comment chain, engineers at startups get fed up of the embedded industry being stuck in the 1980s (long sales process with many meetings and salespeople, custom blobs galore, custom distros, long lead times, high prices etc).
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.
I mean, I won't even try to rebate you, I agree with you, mostly. lol.
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.
> extremely bad integration with tools like Yocto.
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.
I can see where your generalisation is coming from, but again, it's a generalisation. There are a bunch of nice layers that build cleanly with Linus's tree against OE master no problems. That takes work, naturally.
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 :-)
You might be amused that my company literally uses raspberry pi's in production as they are cheap and let us encourage our customers to hack on the robot themselves - https://openshelf.com/
This is targeting hobbyist and not the typical kind of production usage for embedded systems. I rarely heard of embedded people encouraging customers to hack their production system...
Showing as "not reachable" for me. Luckily it's not used for controlling an elevator or a car, or even worse a plane or a bomb, which usually is what "industry" is being referred to.
> 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 know of a few robotics and industrial control companies that integrate RPis into their stacks. They definitely are a real industry tool. I think companies like these are where the limited supply goes.
I have a bunch of experience on this but won't go into much detail because it may be a touchy topic: most companies that do $THING and use SBCs like the RPi are extremely talented at $THING, and not at embedded development. That's why, most of the time, they go into this ecosystem.
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 :-)
I don't think it's that touchy of a subject. I feel most firms understand the a Pi should not be directly controlling machinery that can cause real harm. They shouldn't be replacing PLCs. But imagine use-cases like analytics and reporting or remote access. Or small scale devices like automated lab equipment (where the company's main $THING is biotech).
Exactly, just pretending to ignore the 80% of the market that isn't critical or safety of life and saying it's not true "embedded industry" (or True Scotsman) is just ignoring the reality.
> Rpi actually suck if you compare it to industrial automation PLCs eco-system
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?
These PLC enclosures for PI look to cost as much or more than an actual PLC. Then you have a PI inside that is not designed to handle the vibration, temperature, etc, requirements of an industrial setting right? Why would anyone want this? It just looks expensive and unreliable.
I don't remember the name of the company, but it was a service you bought where you would get network monitoring by placing these small PoE powered boxes all over your offices.
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.
I said "until a few years ago", and AFAIK this was not done by the RPi folks themselves, but by the community. And that's perfectly okay, it's not their market, which is my whole point.
It takes a serious effort and money to maintain a layer. It's not easy to integrate and test everything.
How does Beaglebone look to you (aka: TI's AM335x Sitara line?).
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/).
Beaglebones have been the proving ground of numerous successful consumer electronics. The beaglebone itself isn't a platform but a vehicle for components that are bundled together on a custom board. It's a prototype and evaluation board for their OMAP line.
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.
> It's a prototype and evaluation board for their OMAP line.
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.
Any Cortex A8 would probably suffice. I've been out of the game for a while but there was definitely a vendor push to 64-bit SoCs for even mundane tasks, not to mention all samples being Android based...
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.
Pretty much what the other comment said about the BB being proven etc.
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.
Yeah, building on a literally 10+-year-old chip feels weird coming in from the computer industry. But if its _still_ reasonably popular after this long, I think its clearly got some long-term legs to stand on.
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.
AM3352BZCZ100 is literally #6 on Digikey's list of MPUs right now with 6058 in stock (ignoring "marketplace products"). That's a singular SKU as well, multiple chips in the series means that in practice, the Sitara has more than enough supply.
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.
You may struggle getting 400-500k units in a single bin in Shenzhen, if that is your goal. If it's not, sure, go nuts. I'm from a world where we were spot buying 40k units multiple times a week to avoid being ransomed by manufacturing. I have no idea what the yield is like on those parts but TI's reputation proceeds itself in terms of truly off the charts "go fuck yourself" yields.
Hot take: The advantages of WPA3 makes it irrelevant to most consumers and if RasPi saved a dollar by not including it then I am 100% ok with their decision.
WEP was garbage because it could be cracked in minutes on a laptop. WPA3 is mostly a WPA2 revision that mitigates very expensive attacks.
WPA2 uses AES-CCMP-128 which is not efficient (or even feasible) for high data rates as it cannot be parallelized. WPA3 uses GCMP-128 or GCMP-256, which (in the case of 256-bit) is stronger security and also can achieve gigabit level speeds or higher due to being able to parallelize the encryption.
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.
> WPA2 is susceptible to offline-dictionary attack and the cost is quite low (less than $10), especially with cloud computing.
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.
>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.
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.
> susceptible to offline-dictionary attack and the cost is quite low (less than $10)
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).
WPA3-only is mandatory if you want to use 6GHz frequencies though. At least for the gear we use, that means if you want 6GHz you either must only have devices that support WPA3 or you have to use a separate SSID for 6GHz clients to use. Fallback to WPA2 isn’t permitted.
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.
> 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.
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.
There’s a nuance that I didn’t explain well. WPA2 and 6GHz clients can’t exist together on the same SSID. According to the specification, if you enable 6GHz, the whole network becomes exclusively WPA3. If you enable WPA2, that SSID can’t speak 6GHz. Having new non-WPA3 devices being sold is going to really slow down the adoption of 6GHz, because they can’t coexist. 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.
This is a draconian reading of the standard which I think no reasonable person would agree with.
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.
Dumb spec? There are fundamental limits in this world. Some things are simply mutually exclusive. A dump spec IMO would be a spec that does not acknowledge this.
A spec which uses a new frequency and still makes it impossible to co-exist with existing previous versions of the spec on other, different frequencies is fundamentally dumb.
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.
The single-threaded nature of WPA2 AES-CCMP-128 is the reason (in addition to not wanting to embed known weak security protocols). The higher speeds and later standardization of Wi-Fi 6E (as compared to Wi-Fi 6) made this, in my opinion, a reasonable trade-off.
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.
So instead, it won’t roll out widely for a decade plus due to active incompatibility, therefore rendering its improvements pointless for all but a tiny number of early adopters?
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.
That's the sort of thing that gets put into specs, is completely ignored by everybody except the handful of companies that pushed to get it into the spec in the first place, and eventually generates enough market pressure than even they start to ignore it.
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.
The problem is that if you enable 6GHz on an existing 2.4/5 GHz SSID, you immediately kick off all WPA2 devices. So you have to create a unique SSID for 6GHz devices to use, which is kinda confusing to end users.
When the alternative is no connectivity, resulting in a product that gets returned at ever increasing rates, you have to go and fix the issue.
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.
A big thing with WPA3 is that it mandates protected management frames which means you can no longer be randomly deauthenticated by anyone with a WiFi card.
And it still requires 5v at high current (higher now, gotta buy a new power supply), not supporting the higher voltages most phone chargers can supply a lot of power on.
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.
Arm is by no means legacy. Raspberry PIs stated goal is to produce affordable computers. That specifically means using cheap hardware. Typically cheapness is this volume level comes from reusing components that have had their r&d paid off by high volume or previous successful products. This is pretty much my you don’t see SBCs with current gen smartphone performance. RISC-V may get there eventually, but devices like the raspberry pi won’t be the first place to look
"Raspberry PIs stated goal is to produce affordable computers."
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?
It seems so weird to me when people express this opinion. There was a once in a century global pandemic that so severely crushed supply chains that even car manufacturers couldn't produce cars. What do we expect Raspberry Pi to do when this happens? They apparently have both business customers and hobby customers. They made a decision to prioritize business customers, supposedly because those customers would be more likely to jump ship permanently if they could not get the supply they needed. I have no idea what the financial internals at Raspberry Pi are, but I also know that they did not cause nor want the chip shortage to happen, and it is kind of out of their hands whether such a thing happens again. So without knowing what they really should have done, why fault them for this decision?
> They made a decision to prioritize business customers, supposedly because those customers would be more likely to jump ship permanently if they could not get the supply they needed.
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 recent (lack of) availability to anyone except commercial/industrial buyers
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.
I guess personally I'd rather have a company prioritize businesses over hobbyists especially given that the businesses that typically use products like raspberry pi are smaller businesses that really struggled with chip shortages during that time. It was certainly a frustrating time for everyone involved, but when there is scarcity, someone has to go without, and I guess I just don't mind that they prioritized people trying to build a product. It suggests to me that the company may be able to weather storms and still be around in a few years time.
Nothing proves to me that you haven’t gotten the slightest idea about what you are talking about than the claim that ARM is a legacy technology.
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.
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...