Feedback: lots more WPA3, and then some

Feedback: lots more WPA3, and then some

It's time for me to respond to some recent feedback. As usual, this is a mix of topics and the responses are pretty much off the cuff, so strap in and hold on tight.

At least one person mentioned the 11 hour WPA3 problem on my Raspberry Pis and asked if I was experiencing clock drift. This is kind of funny to me since I've been picky about keeping clocks synced in my personal and professional lives these past few years. So, no, not really. All of those Pis have chrony installed, and it's doing a great job of keeping their clocks disciplined.

I was the crazy person who spent $300 of my own money to buy a GPS-to-NTP box when the unmaintained corporate infrastructure at a certain job was down to its last "proper" time server and was in danger of failing itself. It never came to that, but we got mighty close that winter. If it had fallen over, then I would have "backfed" time into production from the corporate network using a little GPS antenna puck in the window by my desk. How crazy is that?

I've gone to lengths to make things right, put it that way.

Also regarding the WPA3/Pi stuff, someone said "if it is truly cursed, it will be 11 hours and 360 seconds". That would be, what... 11:06:00? I don't think that joke landed with me. I was hoping it would involve "666" somehow, but (11 * 60) + 360 is 39960.

They did mention that an 11:06:40 period is a rollover from 9999999 to 10000000 jiffies with Hz set at 250. That is, if you tick at 250 Hz, after 11 hours, you'll be at 9900000 ticks, and another 100000 ticks past that is 400 seconds, hence the 06:40 part.

Of course, for that to break something, some clown would have to be expressing the time as ASCII digits, and then breaking when it got "too wide". I mean, it happens. It happened to KDE back in September 2001 when time_t went from 999999999 to 1000000000. That was a "fun" one to deal with.

Niels asks how I keep my posts "so level-headed". I guess that's in the eye of the beholder, to be honest. I've had situations where I've deliberately taken every bit of emotion out of my actions, and *still* had people calling it out after the fact.

After a few decades of this, I've concluded that a lot of these results were decided long before I opened my mouth or started writing. They basically have a problem with the overall concept of me saying stuff, and exactly what gets said doesn't matter a whole lot. They just use the words I choose in order to sprinkle it throughout their takedowns.

The way you can know this is happening is when the same words come from someone else who has a different *ahem* "presence" in the same space, and then nothing bad happens, or perhaps it's taken as good. That happens too, and it's really irritating since it serves to confirm to you that it may be the 2020s, but it's really just a number of terms of people being narrow-minded and generally pig-headed.

A reader writes that I should try wpa_supplicant 2.10 on my RPI, and, well, I'm sorry to say that I've done that and then some, and it didn't help. Check it out - wpa_supplicant as built from upstream (hostap's git repo) *does* bring the link up... for about 10 seconds. Then it throws an error and kills it. It looks like this:

Jan 28 13:32:24 rpi5b NetworkManager[847]: <info>  [1706477544.7638] device (p2p-dev-wlan0): supplicant management interface state: associating -> associated
...
Jan 28 13:32:34 rpi5b wpa_supplicant[1209]: wlan0: Authentication with <AP> timed out.

It's a consistent 10 seconds. I was feeling like torturing myself that afternoon, so I started screwing around with the code. It took a while to find where things were happening, but I finally just extended the timeout. It would hold on there a bit longer, then it would die after the new timeout.

So, finally, I just commented out the part where it complains about that and tears down the link, and you know what? It stayed up. So, I went back a little bit, and just let it bring the link up, then suspended it with ^Z and went about my day.

Three hours later, it was fine. Two hours after that, same thing. I kept checking on it into the night. Then, finally, it died early the next morning, even with wpa_supplicant *still suspended*. Here's what it looked like from the AP side:

Mon Jan 29 01:19:23 2024 daemon.info hostapd[6371]: ath1: STA <pi 5's mac address> IEEE 802.11: disassociated

And yeah, that's about 11 hours after I started the last experiment. (I should mention that having to wait 11 hours to verify things absolutely sucks.)

What I gather from this and what a few people have told me so far is that the actual association is kept running by the device itself, and whatever you have running on the host machine (iwd or wpa_supplicant) is basically along for the ride.

Also, I could swear I found a patch from someone to one of those projects that basically says "it's gonna die after 12 hours anyway, so just let it happen and restart the connection then". I can't find it while writing this, but it doesn't matter. Here's what's wrong with "just let it fail": NetworkManager has a limit for exactly how much crap it'll accept, and after the default of 3 retries, it'll just leave the link down.

Sure, you can override this, but now you're stuck with Yet Another Behavioral Patch for any of your machines which might be affected by this. Have fun with that.

Oh, and, obviously, forget about actually DOING anything over that link while it's being restarted. If you care about reliability, this is not a tenable situation.

Once again, if you care about having decent "modern" (as in 2020) wifi on a Pi, go get yourself a little USB barnacle that's supported upstream and go on with life. Or, better yet, just use hardwired Ethernet and forget that the thing even has a radio on board.

I'll pour one out for the sanity of anyone who doesn't have a choice in the matter. At least you're not suffering by yourself.