We can do better than that - beamforming. Better 802.11ac routers use a phased antenna array to change their radiation pattern, steering the RF energy in the desired direction.

https://www.oreilly.com/library/view/80211ac-a-survival/9781...

Heh, eventually the tech changes enough that the "wifi router" misnomer might become correct.

With MU-MIMO, it technically changes from a hub to a switch - MU-MIMO prevents spatial collisions, allowing the router to transmit to multiple stations simultaneously.

As whatshisface alludes to, a wireless router acts as both an access point and a router.

To be fair a lot of people only have a cable box (one ethernet port) and plug everything into their wifi router, which is also the DHCP server, firewall, etc.

I'd guess this is the most common setup for residences, it requires next to no technical skill other then plugging in the cables. Should definitely count as a router here no?

That's also what I do.

Not that I lack the technical skills to do otherwise, but my ISP's router works remarkably well (biband 802.11ac, IPv6, no packet loss, 4 ethernet ports, ...), so it's all I need.

And if I have a weird issue, that's a single device that I need to reboot (and I can even do it remotely).

Same situation for me too. I've done a bunch of networking stuff before with pfsense and plan to again, but I just moved and wanted something working. And it works great!

To be honest it's all most residences need, even if you're a technical person. Half of common home devices (xbox, printers, laptops, etc) have wifi, so for most people 4 ethernet ports is all you need(if any). It's almost 0 setup other then changing the passwords, and it works.

The only reason why it wouldn't work for you is if you have many wired devices, or want to get into the networking stuff.

I'm going to go out on a limb and say that most people don't need any ethernet ports. Most people just have a phone and maybe a laptop, tablet, printer, or smart television, all of which function perfectly adequately over wireless.

Even I don't bother with ethernet. There's no point; with <10 Mbps Internet speeds, too slow is too slow. The only thing plugged into the router is a second router for the detached garage/shop. Occasionally, there's need to transfer large files between two computers (games which can take multiple days to download), but temporarily stringing an ethernet cable directly between them does the trick.

Mostly they have a box that does NAT, firewalling and dhcp, but not routing. Well, it might do ipv6 routing.

"Wifi router" seems reasonable to me because the box in my living room that does the wifi also routes.

Then someone builds a new router called a smart router and the cycle repeats itself .

Doesn’t work in high density though

It does if your multipath is good enough. Enough antennas on either or both sides help.

Technically that power strategy works but in the real world clients don't want to wait a long interval to connect and boosting the power on a short interval creates more RF chaos than you are trying to solve.

There are many standards to assist in roaming such as .11k, v, and r. Particularly for mesh nodes s. In the end the strategy used in Wi-Fi is that the end station is the one that decides when to roam and why. Again it comes down to the client knows more information about what it could connect to and when it makes sense for it to roam than the AP could. The AP can just send hints that it'd like it off of it for other clients benefits.

Many Enterprise systems come with the ability to tune power the same way they can automatically tune channels. Usually they tune against other APs rather than clients since AP positions and emissions are much more static and controlled by the same system (normally).

I’m no expert on these matters, but WiFi roaming is covered by 802.11r and WiFi-meshes by 802.11s.

I assume these specs include mandated behavior in both the APs and the clients.

The Ubiquiti access points and I assume some other brands use the following method to implement roaming:

All of the access points broadcast a certain SSID. When a client tries to connect, they coordinate with each other to choose which one will reply to that particular client. That is, the client things it is connected to one AP and doesn't know anything special is happening.

If the system wants to move your client to another AP it just disconnects you from the first AP and when you try to reconnect the second AP will reply to you.

In a case like that, assignment is driven as much as "having a clear channel" as "having a better connection on the channel". If you had a choice between two channels, once of which was shared and slightly "better" and another you can have to yourself, you are better off having one to yourself. (That way you aren't having to wait for other clients to stop sending or receiving, dealing with interference, etc.)

A corollary to that is that if you have both 5GHz and 2.4GHz support on an access point you do best distributing clients between both sides, even if people think 5GHz is better or that 2.4GHz performs better in real life.

I am amazed that instead of all the silly gimmicks that APs have been marketed with, nobody has come out with one that has a lot of radios working on different channels and just behaves like a large number of APs. Practically I think this would work way better than channel aggregation.

Xirrus sells multi-radio access points to do as you described. The only installs I know of, though, are replacing them with more APs spread around because the Xirrus units just cost too much to cover real world buildings, comparatively.

Is that how Ubiquiti APs work currently, or is this a description of the now deprecated “fast roaming” thing they were doing a while back?

Edit: meant “zero handoff” per replies below.

It's a description of Zero-Handoff in Ubiquiti's 1st-gen APs. Fast Roaming is 802.11r.

Getting good roaming is theoretically not that difficult. Lower transmit power so that the device's RSSI in the locations where it's expected to transition to another AP (or off WiFi) are lower than the device's roam scanning threshold (-70 for iOS). Set the minRSSI on APs to something sensible and enable strict mode so that more troublesome devices aren't able to cling to an AP @ -85.

In practice, tweaking those knobs and figuring out placement and channel planning start to get tough beyond 3 APs.

That type of roaming actually ends up breaking a lot of WiFi implementations — it’s really only super useful for WiFi VoIP phones. I worked with a vendor (Bandspeed) doing that kind of WiFi roaming back in 2005, so it’s not remotely a new concept.

Most other devices will jump to another AP broadcasting on the same SSID if the signal is a lot stronger. It’s not nearly as much of an issue as it used to be, but people expect WiFi to Just Work (tm) so it’s better to let the OS’ network stack manage it.

I think the deprecated thing was "zero handoff". Fast Roaming uses 802.11r

https://help.ubnt.com/hc/en-us/articles/115004662107-UniFi-F...

My understanding is that "fast roaming" and many of the proprietary tricks are just ways to speed up the cryptographic pairing process when you switch AP's. I think the same thing happens, but some steps are streamlined.

Traditionally roaming is left to the client device and most implementations are so bad that they won't give up on an old AP so long as they're seeing beacons every year or so. Who cares that I haven't successfully received a packet in the last hour, it's sure better than the 2 second interruption we'll get if we tried to switch.

I'm only mildly bitter at the useless roaming behaviour of most clients. Turning transmit power down doesn't really help either. Some clients will roam better but other clients at the edge of the coverage now have no coverage.

Using software on my smartphone I can observe that it changes AP it associates with as I walk around the house where I have a “traditional” 802.11r WiFi network with common wired backend. No new DHCP is triggered either.

So it may not be perfect, but it can’t be that bad.

What do you use to verify which AP your device is connected to? I've not found a convenient way to do this for testing.

You need to know the MAC address of each of your access points - also known as the BSSID. It should be available in the admin UI of the access point, and sometimes also printed on a label attached to the AP.

Knowing that, you need something that shows you details about wifi connections, so you can view the BSSID (MAC address of the AP) you're connected to:

Android, iOS: Install the "Network Info II" app

Linux: use the iwconfig command

Windows: Use the command "netsh wlan show interfaces"

Net Analyzer for iPhone shows the raw BSSID (AP mac) for whatever network you connect to.

802.11r solves this. I’ve got it configured at my place and roaming is seamless and takes less than 100ms.

802.11r does not fix this. It makes the handoff slightly more efficient but the client still has to decide to actually do the handoff. And that's the part that never seems to happen, as many clients are stupid.

From my testing with iPhones, the stupid behaviour goes away on an 802.11r-enabled network. I noticed the same issues on a legacy network but that all went away after enabling 11r.

I would imagine that I phones has better roaming preference overall. But maybe having 802.11r enabled causes devices to be more optimistic in their roaming as they know they're not switching networks.

Can you elaborate on how you configured? What hardware are you using?

I had a few Devolo powerline adapters (which include a WiFi access point) and I reflashed the firmware with OpenWrt as a last resort (the default firmware didn’t support 802.11r and it was hell without it). Works great since then and it saves me from buying a set of enterprise-grade APs.