What is the reason for this?
What is the reason for this?
- 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.
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.
The response time of an under-provisioned or poorly implemented API endpoint on a machine in the same rack can be multiple seconds though :(
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).