Hacker News Reader

Comment by jessriedel | Hacker News Reader

The overwhelming issues with WiFi are

1. It is slow to connect, taking multiple seconds rather than a few milliseconds. (Wifi unreliability would have much less practical impact if there was rapid reconnect.)

2. The lack of a sufficiently flexible standard interface for logging in and accepting terms, leading to the terrible captive portal workaround.

I cannot for the life of me understand why the standards committee cares much about various other minor improvements when these issues are still unsolved after two decades. (Similar complaints can be made about Bluetooth.)

View on HN

> I cannot for the life of me understand why the standards committee cares much about various other minor improvements when these issues are still unsolved after two decades.

It's different people.

WiFi is a pretty wide field. There are plenty of people whose interests and/or qualifications only extend to part of it. Should they just sit around twiddling their thumbs if the parts they can contribute to aren't the parts with the biggest issues?

You can re-phrase my main question as: why is there enough interest in doing these minor improvements when there is apparently little interest in fixing the major and long-lasting deficiencies?

In the context of this thread, IEEE aren't the ones who can improve such things. WiFi 6E and WiFi 7 both make considerable improvements on connect time but at the end of the day, they deal with the "backend" if you will.

They have no control over crappy WiFi NIC cards that delay connections or how Apple displays captive portals.

I think what you call minor improvements would be considered significant to others who may benefit from it.

> why is there enough interest in doing these minor improvements...

Why are people working on improvements to wi-fi at all, when there are people around the world dying of hunger?

If you can answer that, I think you'll be able to answer your own question.

No. Ending hunger is hard.

1. Wi-Fi is of course capable of reconnecting fast, so you don't even notice it. When you see a multiple seconds worth of a connectivity gap, it's likely not because Wi-Fi is stupidly waiting. Most probably it's radio interference, or the access point can be overloaded and have not enough resources to service all the connections, so it drops some.

2. Wi-Fi is a transport layer; equally TCP and even HTTP do not offer a generic mechanism for logging in and accepting terms. This needs to be addressed at a different level, but I totally agree, it would be great to have a reasonable standard that's open and is better than a captive portal.

1. When I have looked into this, it turns out the basic WiFi standard has rules about polling rate (allegedly to save power). Like, the standard is literally something like “poll for a few hundred microseconds every couple seconds”. Macbooks even have special workarounds that decrease the connection time by ~half by mildly abusing the standard.

Or it can be multiple access points on the same SSID without 802.11r set up properly

> It is slow to connect, taking multiple seconds rather than a few milliseconds.

What is the reason for this?

For standard Wi-Fi the biggest factors for a fresh association are:

- Discovery. You have to wait to see which saved networks are broadcasting. Broadcasting more often = less efficient airspace for already attached clients. Broadcasting less often = longer delay for clients to "see" the network when they start listening.

- External authentication. E.g. if you're doing RADIUS auth or MAC auth with an external database instead of a PSK exchange there is extra time in setting up this exchange and then waiting for the external authenticator to validate it.

- DHCP / NDP. Wi-Fi assumes you more or less want to emulate a standard Ethernet + IP session but over this new fangled air connection. This is an additional delay for an additional exchange with the services responsible for this. Typical clients e.g. Windows will also perform extra address duplication checks slowing things further.

There are some extensions in more modern Wi-Fi standards for clients that want to "sleep" for long periods, immediately do some stuff, then sleep for long periods (like IoT). Particularly TWT (target wait time). These, and more, are already found in purpose built protocols like LoRa/LoRaWAN though.

Discovery could take up to 100 milliseconds.

All the others, if properly implemented, are speed-of-light things. Eg. RADIUS auth to an external database on the same physical site should easily be doable within 1 millisecond. It's not like that database has a multi-second queue of other users to connect first.

While 100 milliseconds (well, slightly more actually - 100 time units != 100 ms, it's just very close) is the default beacon interval, most clients will scan for longer than that to ensure they hear the best SSID (and AP for that) before initiating a connection just to throw it away/immediately roam anyways. This allows higher beacon intervals to work without the clients thrashing themselves between advertising stations. Also, not every beacon will actually make it through heard so connections generally assume they shouldn't just go with the first time they hear it.

As for how a RADIUS auth should take 1 ms... sure, and updating macOS on an M3 shouldn't take an hour either. I'm not saying how tech should be, I'm saying how it is and which steps often add significant latency as implemented. Even a dedicated Aruba ClearPass authentication server on prem scaled for 25k clients can't handle 1,000 auths/second (ignoring that AD would fall over before then).

Usually the drivers are also part of the problem (both on the AP and the client). Same with OS software around it. Things that should be instant just aren't. E.g. go try to disconnect and reconnect to the same SSID on macOS via the GUI. If you do that in ~1 second you should get an error - not a delay, an error that it hadn't synced up with its own connection state and couldn't possibly figure out how to try to connect. None of that is actually Wi-Fi, if you implement an IoT device with an embedded radio and sidestep a lot of those layers suddenly the protocol is much quicker to connect (still not as fast as some simpler ones though).

You've never dealt with enterprise networks where the auth server lived on a different continent

A different continent is usually a few hundred milliseconds away. (The worst delay I had in my life was between me in Europe and the target machines in Japan, and the round-trip still was about a second.)

The response time of an under-provisioned or poorly implemented API endpoint on a machine in the same rack can be multiple seconds though :(

an edge case you can come up with != typical experience. What you're saying is not far fetched, but also not the common case, especially at home and it's not like this latency only occurs on RADII networks

I feel like those don't explain it though. The most common delay people see is when they click Connect on a network without external authentication. It easily takes a few seconds, but surely that's not all due to DHCP etc.?

That finally explains why this super cheap crappy device where you need to configure the BSSID and IP address statically is so insanely fast to connect to WPA2-PSK compared to every other system no matter how beefy. Thanks! I didn't realize it wasn't inherent to WiFi but all the extras, at least once you know which router you're going for (and the connected-to-before-sleep-mode router is definitely a good bet which it could actively query/probe for)

2 is rather irrelevant to the intended use case: devices connecting to a network with pre-shared credentials. Think cash registers and crop humidity sensors connecting to the internet, not cafe wifi.

1 is kind of unavoidable if you want a massively shared medium, mildly reliable connections once set up, and decent throughput.

1 is not unavoidable. I’ve never gotten a clear answer on the explanation, but the most reasonable ones involve power-saving and frequency-saving strategies (only poll for new connections for a few hundred microseconds per second). And I think these are eminently solvable.

On 2, my question isn’t “why haven’t they fixed #2 for this use case?” it’s “where does the effort to address this relatively small use case come from while #2 remains unaddressed “?

A few hundred microseconds is not enough time to send an announcement at the low bitrates required for noisy channels, and then you need to multiply it by the number of cells in a collision domain. This is a hard limit of information theory and physics.

And it is possible for the vast array of computer scientists in the world to work on more than one thing at a time; this particular work was done by a small team, whose specialties are in any case not suitable for work on better open authentication/consent protocols.

My memory of the consensus, the last time this topic came up, is that the number is in fact less than a hundred microseconds. But it doesn't matter for my point if it's a few milliseconds or whatever. The problem is solvable.

A major problem is that one can only have a single connection. It would be nice to do WiFi Direct or AdHoc mode while being connected to an AP. Being able to use WiFi without losing the AP connection (or having a standardized AdHoc channel for discovery) would replace uses of Bluetooth in consumer devices where Bluetooth is used for the initial connection to join a WiFi - some devices rely on WiFi Direct but the UX is very bad because the AP connection gets lost.

It (almost always) lacks forward secrecy or, indeed, any encryption at all when using unauthenticated networks.

These are much bigger problems.

The fact that they haven’t been fixed is so glaring that one can attribute it to enemy action, not carelessness.

1. Can't remember when this had any effect on my use. Unreliability wouldn't improve either if you cut the connection and reconnected as it would bring down all open connections. No thanks.

2. Been years since I've seen one of those. The use-case is pretty much being abroad or in a really remote area with bad cell reception. And even in those cases it seems those captive portals are going out of fashion.

All in all, so far down the list that I probably wouldn't think of them even if I tried.

It’s been years since you’ve seen a captive portal? I can’t remember the last time I saw a WiFi network that didn’t have a password that also had no captive portal.

I’m pretty sure every airport in the US has captive portal WiFi.

I expect their point, which jives with my experience, is that cell coverage is now good enough that there’s no need to connect to random wifi networks where you have to deal with their portals and contend with worse performance than your cell connection.

In the US signal strengtheners seem to be common in public buildings. But in Europe it's common for big buildings (think convention centers, large multi-story shops, etc) to offer free wifi but have bad cell signal on the inside.

Additionally mobile data tends to be expensive, so lots of people in the lower half of the income spectrum will go with a smaller data plan and use free wifi at every opportunity. Which encourages places to offer it to get those people as customers.

And in some countries, mobile data is cheap and available almost everywhere. Many people don't connect their phones to a WiFi in their daily life. Which may then become a huge security issue, as the phone may not download software updates on mobile data with default settings, under the false assumption that mobile data is expensive.

I can't even get "5g" in my own house. I had to order a signal strengthener (fortunately for no extra cost)... That connects to my wifi. And the speeds make me wonder if we really came that much farther from 3G.

The US mobile infrastructure is an absolute sham, even in the outskirts of a large city. I can only imagine how some entire states fare.

I have an unlimited 5G plan in the US, works like a charm, etc. But once I cross an ocean, the connectivity is suddenly very limited, and mobile data is expensive. So, until I buy a local SIM card, or maybe for a few hours of a layover in an airport, is where airport Wi-Fi may be really helpful.

Take a look at eSIMs. They're crushingly convenient.

Doesn't the cell antenna use significantly more power than WiFi?

In theory, yes, in practice, YMMV. I've never found myself in situations where I felt it was specifically worth connecting to Wi-Fi in order to conserve battery life.

I haven't seen one either. But I haven't needed to connect to a public WiFi point in years. That might be the difference. Usually where there is public WiFi I can just tether on my own phone.

Reply on news.ycombinator.com