Hold on there: WPA3 connections fail after 11 hours | Hacker News Reader

Hold on there: WPA3 connections fail after 11 hours

rachelbythebay.com

423 pointszdw175 comments

Reading that thread, it's failing to rekey properly.

The rekey interval is probably set to 3600 seconds, something dumb breaks after the 10th rekey (36000 seconds), and so when the 11th rekey interval comes around at the 11th hour (39600 seconds) and it hasn't re-key'd, the authentication ends up no longer valid and it disconnects.

Easy way to test this theory:

Set the re-key interval on the AP to like 10 seconds, see if it disconnects after 110 seconds.

sounds like a 16-bit int overflow?

A signed 16-bit integer rolls over after 32767, which is a little after 9 hours and 6 minutes (if we're tracking seconds). An unsigned 16-bit integer rolls over at 18:12 and change. Neither fits the observed 11 hour mark.

HW often used counters to represent multiple seconds so I was thinking something like a 32 bit counter representing the number of 10us elapsed which comes out to just over 11 hours.

Hard to say though since no obvious counter comes out to 11 hours. That being said, a counter of some kind going wrong would be the most obvious reason to experience an issue. Maybe there’s a WiFi frame counter that participates in ratcheting the key used to encrypt each frame or something.

Same issue.

A 32-bit unsigned integer would roll over after ~42949 seconds used as a 10 µs counter. That's just shy of 12 hours at 11:55 and change, not just over 11.

I worked on an embedded system for years that used that exact representation for time. The "fun" part is that it was used to represent real time since an epoch many years ago, and the field was compulsory. Not only would the values roll over every 12 hours, but the system would have to function for a while before even synchronizing to an external clock. Every so often, somebody asks why the next-gen system has four optional 64-bit time fields, and my eye twitches while I rant about time synchronization for half an hour. Then they ask how to compute the time difference between two independent events, and we're literally inside an XKCD comic.

I hope you ask them where the observer's frame is and how fast it's moving.

how about some floating point sizes?

then again, thinking about code with timestamps in float makes me scared

I once wrote a fuzzer for some code that serialized and deserialized a particular data structure that included a timestamp -- the complexity cannot be overstated.

Basically every possible edge case came up: floats can be infinity, negative infinity, negative zero, NaN, and even subnormal. The bulk of the problems occurred because we deserialized the float timestamp and proceeded to do unchecked math on it, then expected it to be a normal value.

What is the problem with subnormals? They're just numbers really close to zero

The way they are represented in binary is distinct, basically you need to add an additional edge case when you're decoding it.

I seeing a screenshot in a programming subreddit showing a financial institution storing monetary data as floats, so I wouldn't be surprised.

I swear John Carmack said somewhere "Time should be a double that starts from 1 billion" or something, for games or VR or something.

Of course when I search on DDG I only get "wow the fast inverse square root"

This one? https://twitter.com/ID_AA_Carmack/status/418158611664097280

How!?

Not sure how mrmincent did it, but when I searched DDG, it didn't come up with anything. I then switched to Brave Search and it was in the middle of the first page, just past the fold. I specifically searched for:

  john carmack time double

I chased these a lot back when I was working on PMF on APs. Yes, and the client either is either attempting an insecure rekey (which will fail) or otherwise losing track of the auth key. It's possibly a race between PMK reauth and GTK reauth. The AP kicking the client off though is correct behaviour for a client not behaving correctly. ().

() I've only seen misbehaving clients since the EAP fixes to this functionality in hostapd years ago, where btw there's a whole pile of discussion on this issue through the last decade or so.

I've worked as an engineer in the Wi-Fi industry. Here's my advice: stay at least one or, even better, two generations behind the current Wi-Fi standards.

Vendors care about only two things: (1) Cost (2) the Gbps they can print on the box.

So today that means 802.11ac and WPA2, unfortunately.

Stability of the software is not a consideration.

I'm the proud owner of a major brand WiFi router, and there is a typo on the admin login screen. Not a good look, but it's the best we've got.

I would argue that OpenWrt is the best we've got. (I grant that the hardware side remains messy)

I grant that the hardware side remains messy

Other than that, how was the play Mrs Lincoln.

Yes, but you usually have to choose hardware that's a couple generations behind, in order to run OpenWrt.

I don't think that's the case, exactly.

You can choose current-generation hardware from a company that chooses to implement less advanced wireless specifications. For example, the gl-inet Flint 2 (MT-6000) runs a fork of OpenWRT out of the box and can be flashed with stock OpenWRT snapshots. That's a very modern piece of hardware that will do wifi 6 (not wifi 6E/7).

So hardware-wise you get the current gen, software-spec-wise you get one generation behind. I don't think practically speaking you're going to feel much pain from using Wifi 6 for the next few years, as it can saturate a 1Gbps link pretty easily.

You could run a separate switch/gateway and a separate Wi-Fi access point. Worth it? Idk

But it’s nice when your Wi-Fi is just a dumb box with almost no settings that you can upgrade independently.

Pfsense (on a Proxmox VM, on a laptop with 2 NICs), tp-link managed switch with PoE on half the ports, all-in-one ASUS box configured as an AP only (and switch). It's only WiFi 5, but in a pinch that could go back to doing everything. Rock solid, with no reboots in years other than what ended up being unnecessary ones. Went 390+ days at one point on pfsense.

No you don't. You just have to learn how to compile things.

I run, and love, OpenWrt, but if you make your wifi with routers configured as 'dumb APs', you can keep most of the complexity on the router connected to your internet. I have had (gasp) non-OpenWrt APs on my network at times.

Currently I have 3 TP-Link AC routers running OpenWrt, RPi 4 running OpenWrt for the router.

The original Street Fighter II arcade game had the same problem, but Capcom managed to fix it: https://fabiensanglard.net/sf2_warrier/index.html

I love these little posts.

I was replaying Resident Evil 2 and this typo broke the climate for me: "Platform Eleveter" https://twitter.com/ResiFacts/status/1189139062197604357 (in moments like that you are reminded, "oh, this is a Japanese game")

I'll note that you have typo'd the typo, it looks like it was "elevater".

I'm leaving that unedited for posterity, thanks for pointing that out

Living in Japan I see so much bad English spelling I’ve gotten used it. Esp. at restaurants it can be very off-putting (e.g. “Flesh Juice” instead of “Fresh Juice”)

See also: KONMAI Quality https://namu.wiki/w/KONMAI (long list of typos and other errors in KONAMI arcade games, including infamously misspelling the name of the company itself)

Psygnosis managed to do that as well, in the C64 version of Shadow of the Beast.

https://www.youtube.com/watch?v=R_GdJiEjSho

Spelling error is at 5-8 seconds in. As that is kinda the first thing you see, it is quite noticable.

Keeping with the video game theme - the Wii version of Okami used a watermarked version of their own box art.

https://www.destructoid.com/oopsies-ign-watermark-on-the-cov...

> I'm the proud owner of a major brand WiFi router

Why not name it?

Asus

I think ax is now 2 generations behind, if we count 6e and 7, and a pretty nice upgrade over ac.

The nice thing about the newer 2 is 6ghz, for people in highly congested areas. I live on an acre and pick up tons of 2.4ghz, some 5ghz. I can't imagine how bad it would be in a modern tract home development, or worse, a large apartment complex.

Not that much worse for 5GHz because a decent wall will already heavily attenuated that signal.

When I was still at university, just walking out of my studio appartement and closing the door would already drop my 5GHz signal a good bit. Open the door, much better.

They are pretty close in frequency IIRC, but in a crowded place I assume every little bit would help. Not sure how much, though.

Of course the -real- benefit to upgrading early is that you'll likely have the 6ghz space to yourself for a couple years.

It’s a trade off. The higher the frequency the worse it does with obstructions, generally.

When concerned with congestion that is considered a benefit ( but you might have to run more than one access point)

Yeah, it’s that second one is the biggie, especially if you’re dealing with something like an outbuilding that either only has intermittent power or even no power at all.

It depends where you live and what the building codes in that area try to address. Here in Tokyo the biggest worries are earthquakes, so my apartment walls usually incorporate wood instead of concrete and the 5GHz signal through my closed door and six layers of rooms only just drops to 2/3 on my phone.

Unfortunately, this also means I'm competing with nearly a hundred different APs in the apartment alone - of which many broadcast in both 2.4GHz and 5GHz - to the point that my Macbook less than a meter away from the router still takes a hot minute to automatically find the AP unless I manually select it.

This topic has been fascinating me because I can't find reliable information.

It seems like most people don't necessarily care per se about wifi performance because you can stuff an AP every 30 ft and call it a day.

Most MSPs seem to become a shop of some kind based around a hardware that isn't necessarily the most performant, but good enough, cheap, easy to manage, etc. (lots of UniFi shops even though I don't consider it a good solution).

In terms of performance, though, I live in a very high density apartment so I have a niche use case: I've been trying to find the access point.

So far, ruckus has been outperforming every other access point I've tried (Aruba, Unifi, extreme, etc.)

I can't find any reliable data on whether or not Ruckus is just literally the best access point, and I still consider myself in the researching phase.

Is there industry knowledge to the contrary? Are there any actual engineering standards that companies aspire to, or is it just a "most people don't measure this, so whatever" industry?

Just went through this for a large site installation. We had to reach out to vendors and have them send us trial units because performance data was impossible to find, it was incredibly time consuming setting up a proof of concept for each vendor AP. Also, this is only really an option open to people who are doing big deployments because it isn’t worth the vendor’s time otherwise.

I’d recommend looking at Juniper Mist for high congestion areas because their auto mode actually works and adapts to changes in the environment.

I do have to ask though, do you really need enterprise Wi-Fi? It’s not very neighbourly but buying a high end consumer Wi-Fi router that lets you pick DFS channels, picking the least congested channel, and setting transmit power as high as it will go should do the job in an apartment.

I need enterprise wifi because I want a bullet-proof network.

Do I actually need it?

Eh, no, I suppose.

But I can't stop myself from not doing it.

Also, in terms of tangibility, my 2.4ghz is so abysmal due to congestion I'm willing to do anything to maximize it. Even Aruba falls flat with this band but Ruckus does an *okay* job. It's obvious that AP performance is a factor here.

My 4x4 Wifi 6 Aruba 535 gets completely shut out by a 2x2 beige colored clunker Ruckus 510 that I got for $40. It's obvious that price, features or "newness" aren't things I can rely on to give me a good picture.

Aruba outperforms my other models -- I've spent a lot of money just testing this out myself using the use case of 40 competing SSIDs.

(According to my research juniper doesn't perform particularly well. Check the Packet6 report that Ruckus cites. Probably biased, but what else is there? "Data sheets" that don't really say much about anything. I havent purchased a test AP, though.)

Also, I forgot to mention that you shouldn't be advising people to use a consumer router if you know anything about technology.

> do the job in an apartment

You should visit Chicago some time.

Care to elaborate?

Chicago has an abundance of deep narrow lots. It isn't uncommon to have to have apartment units that are 14-15 (4.5m) feet wide and up to 80 feet (25m) long, a hallway runs on one side with bed/bathrooms adjacent. There is no way you can adequately cover this with one AP unless you don't care about speed much on one end of the unit. If you want uniform top 5GHz speeds you're going to need 2 or 3 APs.

I run roughly 60 site's wifi across the UK according to my Unifi VM, which has been trundling along for over five years now.

One of those sites is my home, another my brother's home and another my dad's and another is at work. At least one of the others, you might have heard of.

I'm not quite so jaded as @roboman. I suggest you keep up with the Joneses. The latest is wifi 7 and if we get a bit conservative, we might consider 6 as current and hence the advice is stick to wifi 4!

That's not my advice. I suggest that we embrace the latest stuff and learn how it works. If necessary you can always spin up another SSID with special properties.

I've got devices from fridges to ESP80266 wired thingies and laptops and phones and whatever all working fine.

Do you measure WiFi 7 for packet loss? UniFi might be better but I stand by my advice and still suggest 802.11AC or AX for consumer grade router.

I haven't seen any wifi 7 gear. I have a Unifi tri band wifi 6 AP in the next room at home which is a bit excessive. However, I live on the side of a hill and I get coverage across the entire valley.

Unifi tends to be a bit divisive in forums such as HN and r/networking and even their own forums! The wailing and gnashing of teeth at every version update is quite something to behold.

For me as an old school sysadmin, running a Linux VM as a Unifi gateway is fine and has been for years. I treat it with respect and read change logs and I have decent backups and so on.

The vast majority of my customers and my already installed gear is wifi5 and any new APs are 6 by default. I'll wait for 7 devices to actually be available but it doesn't bring much to the table. Wifi 6 with the addition of 6GHz was a major upgrade, 7 not so much.

My phone now has way more bandwidth to my home LAN via wifi than the LAN itself! It can use 2.4/5/6 GHz and each band has more than one MIMO. Its not quite that simple but I will be grabbing some 2.5 or 10Gb LAN switches soon. At work 10Gb with 40Gb uplinks is generally indicated ...

Agreed, I left healthcare networking at a place with ~36,000 APs just around the time 6E was getting its first early release hardware and we had already deployed multiple hospitals with Wi-Fi 6 APs and laptops at the time. As you say, the absolute latest (especially when it's the first round of hardware) can be iffy but 2 back seems extraordinary over-conservative.

I'd even go as far as to say we had as many client tickes from bugs about old hardware from 2 standards (~10 years) ago that weren't receiving patches anymore as we did from the new hardware but at least the new stuff was still getting patches.

That said once you go to consumer/prosumer hardware I'm convinced everything has a litany of bugs that have no hope of getting meaningfully fixed regardless which version you use. For 99% of use cases it'll work fine enough and that's all any vendor selling it will care about, new or old. Often Qualcomm/Broadcom/whoever-made-the-actual-wifi-chip-com will have patched things consumer APs and devices won't have actually updated to anyways.

36,000 is an impressive install.

I’d imagine that every single thing that could happen to an AP would happen.

What hardware did you use?

Mostly HPE Aruba whenever we could, the last model I was involved with testing was the AP 510 4x4 Wi-Fi 6. On the client side the Intel AX200 was the last I was involved in testing for devices we controlled but, being a hospital, tons of old devices came with what they had and we just had to make it work. We even had a WEP SSID (with a crapload of isolation and firewalling) because there were devices hardcoded to a certain WEP network with no WPA* support too expensive to replace. That said, it was also a world of mergers and divestitures so we supported just about every brand at some point since we couldn't justify going in and ripping the existing Wi-Fi out day 1 unless it was truly disastrously designed.

As far happenings to APs I'd say 90% of the time it was one of two classics on infinite repeat:

- (Particularly after a new install) "This AP near my work desk and I've been having headaches ever since" -> "We'll try turning it off, let us know if things stayed the same or got worse" -> we actually turn the LEDs off and leave the Wi-Fi on at first -> They mostly never follow up, if we do they say things are great. There were a few occasions they'd follow up and we'd really turn the AP off but it never resulted in anyone being able to tell when the AP was on or off without us telling them (or a few who knew enough to check the RSSI near the AP of course). The "happening to the AP part" was there were sometimes people would just take them down (you just need a ladder and then spin it unless you put every AP in offices in an enclosure) the AP as the first step and then we'd get outage alerts thinking it had just died.

- (Particularly by maintenance crew, presumably since they had the ladders and comfort level in taking things apart during work) we get an alert that an AP in a warehouse/break/hidden-office-cubby/etc area is down so send someone out -> arrive and maintenance person says the Wi-Fi has been bad today -> See the AP is not physically there, ask where they put it -> "Oh you mean this? I thought they were putting up a security camera to watch me work".

Neither of these things were particularly common at the individual level but when you have 36,000 you refresh every 5 years somehow it becomes something that happens somewhere every week. The other 10% is boring stuff, APs being ripped off by someone pushing a tall cart down the hall, someone decorating the APs with aluminum foil to make the hall look like it has disco balls, water/sewage leaks taking out a ceiling of APs because someone broke a toilet. For the most part these were extremely rare and I don't really blame people often ('cept the toilet one). E.g. you've got a bunch of old patients and try to make a disco hall, you're a good person - just know that'll kill your and the patient's Wi-Fi or you're just trying to get shit to where it's supposed to be and you stacked it on this thing too high - don't blame ya for being in a rush but keep safety #1 it could have easily been a different accident having stuff that high rushing down the hall.

If we count generations that way, then yeah, sure.

But we could also count like: 5, 5 Wave II, 6, 6E, 7.

In this case, 2 generations behind would be either Wi-Fi 5 Wave II or Wi-Fi 6. Those are both quite good! My workplace is just deploying Wi-Fi 6 now, and at home I still have Wi-Fi 5 Wave II.

This advice checks out: at home, I have the WiFi 5 Google-pods "mesh network" with five pods (this is a larger house).

Economy of scale does take a generation or two to get behind in general. Wifi, EV's, heck even apple refurbished macbooks are cheaper because there are more of them (as they are from an older generation).

So "being N generations behind latest tech" is solid advice in general is my point. Thanks.

Multiple access points supporting the same SSID, i.e. ESSIDs, have been supported since the very beginning in 802.11, and definitely much earlier than in 802.11ac.

I thought you could just have the same SSID on the same LAN in 802.11n (WiFi 4), too.

You could, 802.11r/k/v just provides some nice hints for faster transitions, but ultimately it is up to the client, whether it is used or not.

Mesh, however, it is not about roaming (i.e. multiple APs with same ssid, clients connects to preferred one). Mesh is a topology thing (nodes come and go), wireless mesh also means wireless uplink (i.e. the AP you are connected to itself talks to its uplink wirelessly). These are things you use only if you cannot avoid them; metalic connection to each AP is way more reliable.

I have found Wi-Fi 6/ax is mature enough to deploy now. I wouldn’t be touching Wi-Fi 7, considering it hasn’t even been ratified yet.

One generation behind is usually where you want to be because your clients usually haven’t caught up anyway.

Is it really that big of a risk? If you’ve got current gen gear and it works fine then why not

> Stability of the software is not a consideration.

Yeah. I'm pretty sure that I've seen a toggle-able option in some home user routers for them to automatically reboot themselves once every um... day (or some other time period).

Like "we can't be bothered tracking down the memory leaks in shipped software, so lets just implement an auto-reboot of the router".

It's both funny and tragic at the same time.

I wish more hardware had this setting exposed.

My wifi router had a bug that was eventually fixed, but before that I would need to reboot it every hour. That's a simple workaround - if only there was a setting for that.

https://news.ycombinator.com/item?id=35986375

TP-Link Archer AX73's have it. Just logged into one to check.

It won't allow every hour though. The options are either daily, weekly, or monthly, and you can set the exact time.

It doesn't seem to allow for more than one reboot schedule either, so it wouldn't be possible to set (say) 24 different daily schedules 1 hour apart as a workaround.

The same was the case in that Asus router. I just wish every AP had that setting

Maybe for consumer and ubi gear. The enterprisish gear they have to actually support so it get's fixed enough at some point.

No way the big hospital systems / robot warehouses don't light people (VPs and up) up over flaky wireless.

That's actually a hobby of mine, where I look for 5-10 year old forum posts recommending "new" hardware with good OpenWRT support. I order one on eBay for $30, then try it out myself. I now have 3 very stable 802.11ac access points across my home, and a WPS bridge capable of hitting 500Mbps of TCP throughput.

I do suggest using the latest generation client chipsets with driver support in your OS, though. Whether or not a newer client radio talks to a similarly capable AP, it is likely to have better receive sensitivity than older radios.

I also suggest specifically buying Intel client radios. I have first-hand benchmarking experience that shows that Intel radios are very good at receiving marginal radio frames in heavily congested environments. Qualcomm and Broadcom radios might be just as good, but I wasn't able to evaluate them for lack of driver support for my purpose. Realtek/Mediatek/Ralink radios have pretty good drivers, but the actual radios behave notably worse with congestion. I've had friends living in apartments take my advice and switch from Realtek to Intel, and they've reported back significant gains in wifi stability. I'll also note that the original Steam Deck has a Realtek radio, and many people complain about its mediocre Wifi performance. Some people have gone as far as hot air reworking their Decks to have 802.11ax Intel radios, which happen to be pin compatible.

For $30 you can already get used enterprise access points. No OpenWRT, but they perform way better than 500Mbps. Even the ones that are now five or more years old.

I just want to make sure we're comparing the same thing, since data rates are such a nuanced topic. I have two 802.11ac APs communicating at 866Mbps link rate, via two spatial streams at 80Mhz of channel bandwidth. The APs bridge Ethernet traffic using WDS. I can measure 500Mbps of sustained TCP throughout over that wireless link. I believe that's pretty much the theoretical limit for the link rate.

Are you suggesting there are some good cheap APs that can readily do WDS with more than two spatial streams, or wider channel bandwidth? That could be fun to play with, although at this point my WDS link is just for the lols because I've since run cat6 between buildings...

Also curious on the details of your recommendation

In my personal experience just anecdotally one generation is usually fine provided it is on the latest firmware for that device. A notable bonus is the cost is usually much less than the latest generation. The WiFi 6 that I bought about mid-life of 6 was about $150 and is now $75 on Amazon where as WiFi 7 is significantly more. Some may have a need for the extra speed but my WiFi 6 is still plenty fast enough to keep up with my 500mb/s fiber.

in my dorm, back when 802.11ac was the latest standard, having one of few devices which could support the standard gave me a great wireless experience because the new APs supported it and was enabled by the network admins.

besides the algorithmic stability, the new radio bands or their combinations still have merit fwiw.

What "home" hardware are you using?

Best person to ask I've come across all year!

Damn, I was hoping this was going to be a thread about the guy who tracked down the bug in that damn chip and fixed it with some binary patch even though the vendor was completely useless.

I'd like to read that.

I know, right?

There's a misunderstanding in the article and the comments worth clarifying for people on SAE/WPA3 and the 6Ghz/6-E Bands.

WPA3 is only required when operating on the 6ghz bands.

For 802.11ac/ax its not required on the 5ghz bands.

So it is possible to spin up an AP on 6ghz with SAE only, and another AP on 5ghz in WPA2/3 mixed mode. It's not an all or nothing choice for the pi which first of all only supports 802.11ac and secondly does not support 6ghz with the builtin wifi card.

In terms of range and capabilities we've found the mt76 series to be very reliable and support wifi6 and 6-e on the pis with speeds easily reaching 600mbps.

These are the A8000 cards from netgear and the ALFA AWUS036AXML. They're pretty good for what they are. I only wish they were Dual Band Dual Channel.

WiFi 7 will see clients gaining Multi Link Operation capability, they'll be able to simultaneously hit 5ghz and 6ghz and 2.4ghz bands for 2-3x throughput.

It's an interesting failure mode of our current economic system that the fix for this issue will inevitably come from a lone frustrated outsider.

The employees of the company are much better equipped with all the insider knowledge, blueprints, source codes et cetera. But the incentive models for companies essentially guarantee that they'll never go through the trouble of solving a persistent problem for an already-on-the-market product, if the problem is not big enough to cause a recall or substantial numbers of product returns

So our only hope is some amateur sleuth operating from home, stabbing blindly at the card with caffeine and hatred as the only tools in their disposal. But they'll probably solve it, and we'll get to read a cool blog post about it!

One hypothesis: the cipher needs regular key rotation? E.g. (not what WPA3 actually does):

> Encryption keys should be changed (or rotated) based on a number of different criteria: (...) After the key has been used to encrypt a specific amount of data. This would typically be 2^35 bytes (~34GB) for 64-bit keys and 2^68 bytes (~295 exabytes) for 128 bit keys.

* https://security.stackexchange.com/questions/259808/why-shou...

Though this would be bit-dependent and not time-dependent.

I'm guessing that this likely some kind of 'uptime bug':

* https://en.wikipedia.org/wiki/Integer_overflow

i highly doubt they sent 34GB in 11 hours - or, put another way, sent 34GB consistently ever 11 hours such that the keys were exhausted after the same amount of time. This isn't a smart washing machine we're talking about here, just [a] raspberry pi(s)

In exactly 11 hours on three devices, in particular. On one device, the first time it fails after 11 hours could be a coincidence (unlikely, but possible) but repeatedly happening across all three devices suggests something entirely different.

GTK rekey interval is time dependent. Most AP's set it to 3600 seconds by default.

Why are we allowing anyone to use 64 bit keys in 2024? Why is it even part of the WPA3 spec?

To be honest, whoever wrote that bit of the spec should have 'probably part of a three letter agency, don't trust what they say' to the top of their Wikipedia page.

> Why are we allowing anyone to use 64 bit keys in 2024? Why is it even part of the WPA3 spec?

"We" are not, and it is not. That is just a general example of the concept of needing key rotation.

because many programming languages dont support anything beyond 64 bit integers.

Maximum integer size on a CPU or in a language has nothing to do with key sizes for serious (non-toy) cryptographic systems. Use multiple integers, likely in an array, if needed, as has been done for a very long time.

Yes, it's not usual for the rest of the software to think about these as integers at all, they're just a bunch of bits, like a JPEG so yes, the 128-bit key would be e.g. Rust's [u8; 16] exactly 16 contiguous bytes.

The encryption algorithms themselves, if they're even written in a high level language rather than supplied as machine code, perhaps using hardware acceleration, may treat this some other way, but that's completely irrelevant to you in the rest of the code. Maybe it sees this as [u16; 8] or as [[u32; 2]; 2] for some reason, you don't care.

Turns out that that text is incorrect and it's 64-bit and 128-bit block sizes. The text on the cheat sheet page has been partially corrected to now say 128-bit block size, but still says 64-bit key size.

The current version of that page reads as:

> This would typically be 2^35 bytes (~34GB) for 64-bit keys and 2^68 bytes (~295 exabytes) for 128-bit block size.

So it's sloppy writing that's the issue, not that people are still using 64-bit keys. (I had a similar question reading the quote above and followed the link where this was pointed out.)

I’m not a crypto geek! But, I thought the block size had to be smaller than the key size?

There's no rule that you need to mix a raw key bit with every data bit. Block ciphers usually expand their key into a bunch of subkeys to use in different rounds, and you can stretch that expansion as far as you desire.

And if you squint, a stream cipher is just a block cipher with a stupidly large block.

I have seen issues with apple (Mac and iPhone) devices loosing connectivity on wpa2 after each rekey. Symptom is the device drops offline for several seconds, sometimes connecting another network if one is available. This wreaks havoc with FaceTime calls. I’ve also seen iPhones drop off wifi entirely if another network is not available until you disable and re-enable wifi

I found that extending the rekey interval makes it happen less. I think i set the interval to something very large

I’ve always thought this is due to Wi-Fi Assist [0] being less than helpful? Never tested any further though

[0]: https://support.apple.com/en-us/102228

I don't think that is the problem, just something that kicks in after the problem has happened and wifi has disappeared. Eg, on my macbook, I was loosing wifi every hour before I tweaked the settings on the router.

This happens on my iPad also at around the same time each night! I thought it was my router being bad.

I suspect that this patch https://w1.fi/cgit/hostap/commit/?id=b0f457b6191aa8ee329331c... may fix the issue although the default key lifetime is 12 hours not 11 but maybe there is something which runs every hour and checks which keys will expire within the next hour. New technology like this is often horrifically under tested and there must be so many bugs for those who go hunting.

Can someone explain to me why don't we have open source WiFi chips?

Are they so complicated that we can't get a open hardware pcie adapter?

Likely due to regulations, fcc, certification costs, etc.

The hard part of open hardware isn't the technical complexity by itself. I'd even go so far as to say there is no such thing as something so complicated we can only make a closed implementation of it, just see Linux. The questions are more like "Do you want to fund the hardware investment, including legal certifications since this is consumer radio technology, on the hope it'll sell enough to make it back?", "Do you want to continuously design new versions to new standards every 5 years so it doesn't just become obsolete anyways?", "Do you want to maintain the firmware and driver, answering all of the issues that come about connecting to thousands of other devices across thousands and thousands of pages of standards behavior you or they implement poorly?", and, moreso, "Do you want to do this for the rest of your life all out of principle that client Wi-Fi chips, which the high end of the latest generation go up to a whopping $16.55 per in bulk, sometimes have bugs and you can't go in and just fix the particular bug you want to?

Now sure, maybe you can convince your closest 10 dozen friends interested in open source hardware to not put everything on one person but at the end of the day there are a few people it's going to be a significant burden on and they have to see it as a worthwhile burden otherwise nobody is going to run the project. It'd probably be easier (though not easy) to stir up enough support to convince an existing manufacturer to make their firmware open source instead.

Even much simpler chip functions tend not to have an open-source implementation. Open-source doesn't mesh very well with the economics of chip fabrication, is the main reason (in general it doesn't work with hardware as well, but chip fabrication is probably the most inaccessible of hardware types). And yes, wifi is complex. Probably the only function more complex is cell phone radios.

It would be complicated and expensive (yes, WiFi is that complicated), and you likely couldn't sell that open hardware adapter so there's no motivation to make one.

The law states that "an intentional or unintentional radiator must be constructed such that the adjustments of any control that is readily accessible by or intended to be accessible to the user will not cause operation of the device in violation of the regulations" (https://www.law.cornell.edu/cfr/text/47/15.15 )

So if the manufacturer makes a device where changing the firmware is "readily accessible" to the user and there is an open source firmware available that can circumvent the FCC transmission restrictions (for example, change the power limits or channel limits for wifi physical layer), then that would be grounds for FCC refusing to certify that device, as it is not permitted to make, import or sell general unrestricted transmitters to the general public (there are certain exceptions for licensed operators, ham radio, experimental use by manufacturers etc).

It's similar to other clauses that prohibit manufacturers from making it easy for the user to modify the equipment - e.g. 15.203 (https://www.law.cornell.edu/cfr/text/47/15.203) "the use of a standard antenna jack or electrical connector is prohibited." so that the user can't easily replace the antenna with a different one from what was certified.

There is some open source firmware for very old WiFi chips:

https://wiki.debian.org/Firmware/Open#Radio

There is also some FPGA based open source WiFi SDR things:

https://github.com/open-sdr/openwifi

To my understanding, the main difficulties are:

1. The investment needed for a real "free" Wi-Fi chip is much higher than most people's (FPGA, DIY, enthusiast and garage guys) imagination. I won't go through all the complications (not only design, but also tool chain, cell libs, etc.) here. Just one hint: think how many thousands pages are there in the Wi-Fi standard pdf, and how many test cases/vectors would be extracted from that before the actual tape out.

2. The chip business is purely the game of volume – if we want to not just burn money, but actually make it successful from the business point of view. We discussed with some businessman, investors and big companies in the chip/Wi-Fi industry regarding the "free" Wi-Fi chip business opportunities and failed to convince any of them. In other words, so far, no serious man actually believes that the "free" Wi-Fi chip could be financially successful.

(Keep in mind the game of volume). A key question to you: Will you buy a Wi-Fi dongle (with free Wi-Fi chip) with higher price and lower performance/functionalities (This is the result of low investment and low volume compared to those big players: Qualcomm, Broadcom, Mediatek, Realtek, etc.)? Even if you say you will, could you estimate how many people are there like you in this world? For chip: NO volume == NO business.

This is Xianju who created the opensource Wi-Fi chip project openwifi: https://github.com/open-sdr

It is still in FPGA status, not a real chip yet. We have been working on this for 7 years (starting from the time project setup internally).

> Broadcom/Cypress/Infineon CYW stuff

> My conclusion: this entire ecosystem is deeply cursed

There is no curse, but cheap junk sold for premium price! Those components are designed for cheap laptops and tvs. Building networks and servers out of this foolish!

If you want stable WiFi, get Intel card connected over Pcie, not USB! It is like 20 USD with official WPA3 support!

Uh? I thought Broadcom and Infineon made very solid stuff...

Pi is build from cheapest components!

Broadcom is famous for their terrible Linux support (typical android style binary firmware blob dump). Many drivers are unofficial, only reverse engineered. Some commenter here even mentions patching binary blobs to fix issues!

Murata Type1GC mentioned here, goes back to 2015. It also has several compromises to keep size small. Hardly stellar config!

Well the Pi isn’t trying to be expensive or high end. But it’s generally pretty stable tho.

What would you recommend instead that fulfills a similar role?

it's not like you have an option (out of china)

Question for those with more experience - I’ve just purchased a Pi Zero 2 and I’ve been having real issues with the WiFi since I opened the box. Is it likely a faulty device?

It should connect and stay connected for 1 hour or so. Network transfer speed should be at least 1MBps.

It is quite possible unit is fine, but there is just interference at your place. Those small antennas are not good at dealing with it.

Thanks. Will try moving to about to see how it goes.

To follow up, I moved the device to be right near the access point and it worked ok. So now I need to figure out what I’m going to do when it’s in situ…

probably.

bottom barrel price hardware components usually mean top quality component that failed QA and then went on a lower quality bin and then passed QA there.

it's not a different design or anything. the car analogy would be all factories making only 4x4 cars and the cheap cars just being the 4x4 with the trans axle broken or something, resulting in two wheel drive (doesn't even care which two wheel because the cheap bin QA just test if the car moved). you probably got a chip with two trans axle broken and the chip limped with one wheel drive thru QA and they called it a day.

thanks artificial Monopoly protections via bogus IP laws.

Broadcom at least are certainly capable of making reliable network devices, their switch ASICs [0] are very common.

[0] - https://www.broadcom.com/products/ethernet-connectivity/swit...

I don't know if I'd call Airoc (Infineon) "solid," but they're the least cursed standalone Wi-Fi+BT modules I'm aware of.

There's always WINC1500 or ESP-AT if you want your product to be trapped in the stone age.

Ahhh I wanted to use the esp32, and thus the esp-at for some specific stuff, but I'm a bit clueless about what else is available and what I'd be missing. What are the more stone agey parts of it?

An obnoxious mountain of binary blobs, no 5 GHz, no WPA3, and if you plan on using Bluetooth, you're gonna have to re-flash the ESP every time you want to add a new GATT attribute.

After the i225 intel fiasco I don’t have much faith in them being much better.

I think days of good support from intel on linux are gone unfortunately. Try finding an AP capable intel chip with Wifi6 for example and even older chips are a bit of a shitshow. My iwlwifi driver fails to bring up the bluetooth controller in 1/10 cases (both after power up or sleep).

AX201s have always worked perfectly for me.

The ax201 does not support AP mode, AFAIK none of the recent Intel cards do.

No AP mode for Intel cards:

https://www.intel.com/content/www/us/en/support/articles/000...

> The thread runs for close to a year, and then just stops cold in August 2022 with no resolution.

"Who were you, DenverCoder9? What did you see?"

* https://xkcd.com/979/

Some datascientist out there should crunch the numbers and give us the probability that an XKCD link will appear in any given HN post. I bet it's fairly close to 1.

One day we will have an "XKCD number", to represent how far from an XKCD reference any existing concept is.

Maybe the useful XKCD number would be the proportion of comments before and after the first XKCD reference? There’s also the “true XKCD percentage”, which could exceed 1 for highly XKCD’d topics.

> the useful XKCD number would be the proportion of comments before and after the first XKCD reference

That would be XKCD velocity, I guess.

Velocity is indeed a nice idea.

According to XKCD’s law, the probability to have an xkcd reference is proportional to the number of comments (see https://ploum.net/xkcds-law/index.html )

But adding velocity is really nice. Should think more about it…

I don't consider myself a datascientist but I did some HN x XKCD analysis a while ago. The HN dataset is hosted on Google BigQuery and it is included in some TB per month of free tier processing you get. I.e. you can answer your question quite easily. See my stuff if you are interested: https://www.quaxio.com/hackernews_xkcd_citations/

Great post!

You should submit a Hacker News post for it!

Feel free to resubmit it on a slow news day -- my submissions tend to fizzle out.

The even better case is when the user posts “nevermind, found the solution”, but doesn’t post the solution, and marks the thread as “[RESOLVED]”.

More recent Pro variant on the theme:

You have a problem. You get a Google hit to a Reddit post. The top-voted Reddit comment has replies saying "That worked! Thanks!". But the comment with the answer is deleted, or replaced with boilerplate text protesting Reddit enshitification (and sometimes also advertising the automated tool to do this scorched-earth redaction yourself).

Like both Reddit and the poster with the answer once at least partly understood the altruistic open-sharing global good that the Internet could be, but then they both forgot, or decided other things were more important to them.

Fortunately, you can sometimes recover the answer from archive.org.

And even better when that person is you.... and you can't remember how you fixed it last time.

Usually when this happens I eventually realise that I'm the problem. By which I mean I'm doing something stupid/obviously wrong. If nobody else has this same problem with a common bit of software then I'm likely making a typo on the command, not completely following the instructions etc

Is this for that one particular chip, or for every WPA3 device?

Imagine having a teams call, or playing a computer game and your brand new router disconnects you every 11 hours. And since 11 hours.. this crash will cycle by 1 hour every day - so sometimes the disconnects are at night but sometimes during the day, so unpredictable (especially as some lack of power resets the clock too).

An alternative to the rekeying interval is potentially a DFS channel being used and a radar or causing a channel switch.

Just a reminder that the original ath9k driver supports WPA3 and 802.11s mesh without any hacks. The open source wifi ecosystem is not cursed... although we are stuck with old hardware.

I recently found out that WPA3 and especially WPA2/WPA3 mixed were having issues with WiFi roaming - as in, with 2 access points, devices were not switching from one to another unless one of them just drops the client to force a reassociation.

I ended up just using WPA2, as I don't have any 6GHz or WiFi 7 APs.

On a side note: this person's blog is pretty amazing. Is RachelByTheBay someone famous?

"It's not a bug, it's a feature". This way we know you are really serious of keeping the thing going, by making sure that every 11 hours you are THERE by "turning it off and on again" (to quote the the IT Crowd)

This is the hardware version of Netflix's "Are you still watching?"

Solution: Disable encryption for WPA3 (open/owe), use wireguard for device -> router connection security.

But is there an automatable workaround?

Even a 'no' to this question would be a useful addition to this article.

yes, but it's relatively uninteresting; you could just reboot every 10 hours and 59 minutes, for example. You could check the outuput of a ping command and if it stops giving new sequence numbers or whatever ifupdown the interface, and so on.

So say a scripted reboot, like in a cron job, is that what you're talking about? Automatable is important. I suppose the script would have to run as root or with suid root? And thanks for the reply.

I would probably use a systemd timer instead because it has a feature that most crons don't. You can tell it to start the reboot 10 hours and 55 minutes after the timer was started, regardless of time of day or other clock concerns. that means you don't need valid global time or anything to schedule it properly and it'll be built in to the already there raspberry pi os (and most other distros for the pi) so there's no new software to install or setup.

Thanks!

Or could you just establish a new connection on the same cadence?

Posting workarounds is quite fraught because as soon as you say that there's a workaround, upstream responses tend to immediately become "has workaround, wontfix"

Any way to get OpenWrt on Pi to serve WPA3? I was hoping to test WPA3/OWE for a fairly important project, no dice. Timeframe was such that I didn't have time to find another OpenWrt device, so I just hope it works...

PCAP or it didn't happen

11 hours = 39,600 seconds

Max signed int16 = 32,767

Maybe a signed overflow?

What happened to the other two hours

I went "ah, that explains it" when I saw "Broadcom" in the description of the chipset.

Or another reason to go with a real computer on eBay vs a RPi and loads of other equipment.

According to the article, this has nothing to do with Pi and is more about WPA3 itself

Unclear if WPA3 or this specific Infineon chip. Most likely it’s a chip issue where some counter overflows or something and suddenly the crypto starts failing.

My read was it’s the chip/driver combo.

And the Pi is not the only thing to use that chip, it’s just very popular.

So even if one’s attitude is “get a real computer” like the first post in this thread you may still find yourself with this same chip.

I can easily buy either

1. The chip works perfectly but it's documented badly/ wrongly, e.g. doesn't spell out the whole strategy needed for a periodic key renewal or does so confusingly - driver is written to match the docs or at least the best understanding of these docs, and unfortunately this defect arises after 10 hours but devs with the actual docs have never tested for that long.

2. The chip has a bug, it's not possible to use it correctly per se. Every few hours, just reset it and start over, thus a "good" driver should do resets when quiescent. e.g. After 2 hours, if you did no work for 60 seconds, reset it, after 4 hours make that 15 seconds, after 6 hours, 5 seconds, after 7 hours immediately on quiescence, and after 8 hours just reset immediately rather than wait for the bug.

[Edited to fix numerous typographical errors]

It sounds like it works on the vendor driver. So if there is a chip bug there has to be a way to work around it. We just don’t know what it is.

The second happens all the time. Drivers are absolutely chock full of workarounds for hardware bugs.

Although I don’t think this issue relates to the pi, but I agree, some people think pis will do anything and everything just because you managed to hack some components together, sure, it might works but it isn’t reliable, build a proper computer for that task and save yourself the trouble.

Yes, curse these low power cheap system on a chips! All embedded software should be run on x86! Routers on x86, phones on x86, smart thermostats on x86. Just buy them on eBay am I right.

> All embedded software should be run on x86! Routers on x86, phones on x86, smart thermostats on x86.

In 2013, Intel made an attempt to make x86 suitable for embedded purposes with the Intel Quark microcontroller:

> https://en.wikipedia.org/wiki/Intel_Quark

and branded developer boards for it under the name Intel Galileo:

> https://en.wikipedia.org/wiki/Intel_Galileo

As far as I aware the markets rather preferred existing microcontroller solutions instead of Intel's offer.

Maybe they'll try again with x86s.

MCUs are all about peripherals. The ISA barely matters. The peripherals are frequently ported forward unchanged or enhanced in forward compatible ways from older MCUs with different ISAs because they are specialized, proprietary, carefully refined circuits and developers can port their working C peripheral drivers with minimal change. You can't helicopter in to that market with your half baked, brand new peripheral suite and expect everyone to adopt it.

Intel did go far in set top boxes and smart TVs with their atom/canmore (SoC, not MCU) platform in ~2008 and onward. I ported some media software to it. I think a lot of that has been given back to ARM and Android since, however.

"cheap"

Intel kind of abandoned embedded recently, but 80186 was x86 for embedded before it was cool. And they've tried to make it work from time to time.

x86 routers are great. x86 phones aren't awful, and could have been amazing if Intel didn't cancel them right before Microsoft released Continuum.

Not sure if I've seen a smart thermostat on x86, but I dunno sure, as long as its got a common wire do it can pull power, should be fine.

Pretending for a moment that x86 and Raspberry Pi are the only options: If Pis are constantly broken in all kinds of weird little ways that take forever to debug let alone fix, and x86 just works reliably, then yes honestly that is a valid conclusion to draw.

dev time isn't free -- if it works, it works.

Eating up life-cycles with broadcom/infineon issues sounds like one of the circles of hell , personally.

The problem is not the CPU architecture, it's everything else: no standardised boot mechanism, no hardware enumeration at all, proprietary blobs everywhere, no mainline kernel support, no vendor support 6 months after launch, etc.

And yeah, I do in fact have an x86 router: it's probably going to last for a decade, with software updates and all.

"Here's a nickel, kid." http://www.miketaylor.org.uk/tech/eta/doc/dilbert.gif

Reply on news.ycombinator.com