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.
Or another reason to go with a real computer on eBay vs a RPi and loads of other equipment.
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.
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.
Maybe they'll try again with x86s.
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.
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.
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.
"cheap"
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]
The second happens all the time. Drivers are absolutely chock full of workarounds for hardware bugs.
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.
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.
"Here's a nickel, kid." http://www.miketaylor.org.uk/tech/eta/doc/dilbert.gif
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.
how about some floating point sizes?
then again, thinking about code with timestamps in float makes me scared
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"
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 doubleI 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.
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.
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.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!
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.
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.
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)
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?
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 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.
After the i225 intel fiasco I don’t have much faith in them being much better.
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':
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.
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.
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.
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.
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.
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?"
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
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"
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?
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.
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:
Likely due to regulations, fcc, certification costs, etc.
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.
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?
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
This happens on my iPad also at around the same time each night! I thought it was my router being bad.
I’ve always thought this is due to Wi-Fi Assist [0] being less than helpful? Never tested any further though
11 hours = 39,600 seconds
Max signed int16 = 32,767
Maybe a signed overflow?
What happened to the other two hours
"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?"
An alternative to the rekeying interval is potentially a DFS channel being used and a radar or causing a channel switch.
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.
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 went "ah, that explains it" when I saw "Broadcom" in the description of the chipset.
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!
PCAP or it didn't happen
On a side note: this person's blog is pretty amazing. Is RachelByTheBay someone famous?
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...
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.
Solution: Disable encryption for WPA3 (open/owe), use wireguard for device -> router connection security.
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.
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)
Yes, but you usually have to choose hardware that's a couple generations behind, in order to run OpenWrt.
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 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.
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.
I grant that the hardware side remains messy
Other than that, how was the play Mrs Lincoln.
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 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".
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.
I love these little posts.
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.
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.
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.
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.
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 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.
You should visit Chicago some time.
Care to elaborate?
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.)
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
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.
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.
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.
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.
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.
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.
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.
Is it really that big of a risk? If you’ve got current gen gear and it works fine then why not