WiFi fast roaming recommendations?

[Kirkhaan]

I'm planning to upgrade WiFi in my home. Currently I have:

• Motorola SBV5121E cable modem (owned by Cable company)
• Asus RT-N66U wireless router connected to modem via Ethernet
• Ubiquiti Unifi UAP-AC v2 WiFi access point connected to router via Ethernet + PoE

The cable modem will stay. The wireless router and AP get an upgrade.
Important for me it that the router and AP support fast roaming (my present system does not support this, and it annoys me!)
I've been looking around and are very pleased by what Edimax Pro offers.

But I thought, lets also check here. Anyone suggestions for a Wireless Router + AP that support WiFi fast roaming?

Thanks!

[Halcyon]

If you're looking for a wireless access point (only) I would *highly* recommend one (or more) of the Ubiquiti Uni-Fi access points. Their performance and reliability is just fantastic. Something like the UAP nanoHD are great little units. All of the Ubiquiti gear supports IEEE 802.11r (Fast Roaming) but it's off by default due to serious security issues with it. See https://www.krackattacks.com and https://nvd.nist.gov/vuln/detail/CVE-2017-13082 for more information about those vulnerabilities.

May I ask why you specifically want fast roaming to be on?

I currently run 3x UBNT UniFi AP AC Pro's in my home with 802.11r turned off. Devices "roam" just fine between them. However roaming on Wi-Fi is far from perfect, in fact it's quite terrible, even with 802.11r enabled. It was never designed for it so it doesn't do things like hand-over between radios (like a normal cellular network would).

As for a router, a small embedded PC running pfsense is leaps and bounds ahead of all consumer and even some commercial/enterprise products. Even Ubiquiti's routing products aren't up to scratch in my opinion.

My recommendation is get yourself a good, high quality enterprise access point, a single unit with high gain should easily cover even a moderate to large sized home (depending on the RF environment). Run a separate router to do routing/firewall tasks. Keep 802.11r disabled and use a strong WPA2 pass phrase (or even better, RADIUS authentication with certificates, but you really need to know what you're doing with that one).

[Monkeh]

All of the Ubiquiti gear supports IEEE 802.11r (Fast Roaming) but it's off by default due to serious security issues with it.

Long patched.

May I ask why you specifically want fast roaming to be on?

Perhaps he'd like to use 5GHz.

[Halcyon]

Long patched.

Sources? Because as far as I know, many manufacturers have "patched" it by disabling 802.11r and have recommended against its use. The method in which it operates hasn't changed. There are also recent concerns over the upcoming WPA3 standard which is reported to have similar issues.

I run the latest Ubiquiti firmware on all my radios and it's still possible to configure them in a way to make them susceptible to KRACK. As far as I know almost all access point manufacturers are in the same position.

Perhaps he'd like to use 5GHz.

Disabling Fast Roaming doesn't reduce your ability to use 5 GHz networks. They are two entirely different things. I *only* use 5 GHz at home yet don't use fast roaming.

[Monkeh]

Long patched.

Sources? Because as far as I know, many manufacturers have "patched" it by disabling 802.11r and have recommended against its use. The method in which it operates hasn't changed. There are also recent concerns over the upcoming WPA3 standard which is reported to have similar issues.

I run the latest Ubiquiti firmware on all my radios and it's still possible to configure them in a way to make them susceptible to KRACK. As far as I know almost all access point manufacturers are in the same position.

https://community.ubnt.com/t5/UniFi-Updates-Blog/FIRMWARE-3-9-15-8011-for-UAP-USW-has-been-released/ba-p/2169339

[UAP] KRACK AP mode patches for 802.11r.

If that still isn't fixed, well, please stop recommending broken stuff..

Perhaps he'd like to use 5GHz.

Disabling Fast Roaming doesn't reduce your ability to use 5 GHz networks. They are two entirely different things. I *only* use 5 GHz at home yet don't use fast roaming.

Utilizing a single 5GHz AP is wholly impractical in a great many properties, hence the use of multiple APs. This is why we have fast roaming.

[Halcyon]

Monkeh, I think you're confusing yourself a little.

ALL Access points which support 802.11r are vulnerable, whether it be Ubiquiti, Cisco, Netgear or D-Link. Ubuquiti's fix (as I mentioned in my last post) was to disable Fast Roaming (by default) and add a warning in the firmware that enabling it can leave you open to vulnerabilities. If you read Cisco's or Aruba's documentation, they all explain the same thing.

I stand by my recommendations, even to the extent that I use it at home, even as a network and wireless expert (by profession). There is absolutely nothing wrong with the gear, just about anything can be vulnerable if misconfigured or you don't know what you're doing, regardless of how up-to-date the manufacturer's firmware/software is.

Can you explain WHY a single 5 GHz (or 2.4 GHz AP for that matter) is impractical rather than just citing "many properties" (whatever that means). I use multiple access points as I have a large split level home and I run more than one 5 GHz network simultaneously. I also do this to improve outdoor coverage. For the average home user that just wants a single WLAN, one decent quality access point is usually fine.

[Monkeh]

Monkeh, I think you're confusing yourself a little.

No, no I'm not - FT was fixed.

ALL Access points which support 802.11r are vulnerable, whether it be Ubiquiti, Cisco, Netgear or D-Link. Ubuquiti's fix (as I mentioned in my last post) was to disable Fast Roaming (by default) and add a warning in the firmware that enabling it can leave you open to vulnerabilities. If you read Cisco's or Aruba's documentation, they all explain the same thing.

No they don't.

https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-13082)_FAQ

Yes, customers can safely use 802.11r after upgrading to the firmware version that includes the fix.

Here's the primary commit to fix FT in hostapd: https://w1.fi/cgit/hostap/commit/?id=0e3bd7ac684a2289aa613347e2f3ad54ad6a9449

I stand by my recommendations, even to the extent that I use it at home, even as a network and wireless expert (by profession). There is absolutely nothing wrong with the gear, just about anything can be vulnerable if misconfigured or you don't know what you're doing, regardless of how up-to-date the manufacturer's firmware/software is.

Honestly, I'd recommend UAPs too. I deploy them also - and I don't fear the .11r, because it was fixed.

Can you explain WHY a single 5 GHz (or 2.4 GHz AP for that matter) is impractical rather than just citing "many properties" (whatever that means). I use multiple access points as I have a large split level home and I run more than one 5 GHz network simultaneously. I also do this to improve outdoor coverage. For the average home user that just wants a single WLAN, one decent quality access point is usually fine.

5GHz wall penetration is often appalling. One property I have UAPs in has difficulty with 2.4GHz signals at a range of about 30 feet, let alone 5GHz - nothing, and I mean nothing, will connect to the central AP on 5GHz from that wing of the house. And it's nothing but studwork and plasterboard.

To achieve my desired throughput at home I require three 5GHz APs in a single small house due to block walls - 2.4GHz simply doesn't perform, and 5GHz drops off when I go round a corner. Hence, fast roaming.

[Halcyon]

Monkeh, so now're you're linking me to another page, that explains exactly the same thing I just mentioned.

We can keep going back and forth with this, but you are wrong. 802.11r (AKA Fast Roaming) is still vulnerable if you enable it.

To put it simply: IF YOU ENABLE 802.11r, YOU WILL BE VULNERABLE TO KRACK ATTACKS.

Also whilst 5 GHz penetrates less than 2.4 GHz (because, science), standard gyprock is barely a problem. Even through walls I can connect at 600+ Mbps on 5 GHz. What is far more likely to affect your Wi-Fi performance is your RF environment, band plan, neighbouring access points etc... etc... If you think you can just set your AP to "auto" and expect the best, you are mistaken.

[Monkeh]

Monkeh, so now're you're linking me to another page, that explains exactly the same thing I just mentioned.

We can keep going back and forth with this, but you are wrong. 802.11r (AKA Fast Roaming) is still vulnerable if you enable it.

To quote information from the two links YOU supplied:

I currently use Adaptive 802.11r. Is my network vulnerable?
Yes, the vulnerability affects all versions of 802.11r including adaptive 802.11r. The feature can be used after upgrading to the firmware version that includes the fix.

I currently don’t use 802.11r. How will I know in future if I accidentally enable 802.11r on an affected firmware?
Starting October 16, 2017, “Access Control” page will show a warning if customers try to enable 802.11r on an affected firmware version.

To put it simply: IF YOU ENABLE 802.11r, YOU WILL BE VULNERABLE TO KRACK ATTACKS.

I'm sorry, but no, I am not wrong. Please take a moment to read the page and the quotes you have just selected. With updated firmware the attack has been mitigated and 802.11r remains functional and secure.

Also whilst 5 GHz penetrates less than 2.4 GHz (because, science), standard gyprock is barely a problem. Even through walls I can connect at 600+ Mbps on 5 GHz. What is far more likely to affect your Wi-Fi performance is your RF environment, band plan, neighbouring access points etc... etc... If you think you can just set your AP to "auto" and expect the best, you are mistaken.

And now we're operating on the basis that I am clearly an idiot and don't know what I'm doing. Okay.

[Halcyon]

I'm sorry, but no, I am not wrong. Please take a moment to read the page and the quotes you have just selected. With updated firmware the attack has been mitigated and 802.11r remains functional and secure.

Monkeh, if you bothered to read your own sources, they all recommend you don't use 802.11r. Some manufacturers may have tweaked the way it works (i.e: disabled certain parts of it) but the vulnerability is built-in to the standard. Once they deviate from the standard, it's no longer 802.11r and doesn't work.

What you are saying goes against most manufacturer's recommendations which recommend leaving 802.11r switched OFF, even with the latest firmware. Forgive me if I accept the advice given by Cisco and Aruba over your opinion. You can have the last say if you wish, but I won't be responding to this any further. I suggest you and others do your own research and work out if the risk is applicable to you.

OP: Read my first post, that is what I recommend.

[Monkeh]

I'm sorry, but no, I am not wrong. Please take a moment to read the page and the quotes you have just selected. With updated firmware the attack has been mitigated and 802.11r remains functional and secure.

Monkeh, if you bothered to read your own sources, they all recommend you don't use 802.11r. Some manufacturers may have tweaked the way it works (i.e: disabled certain parts of it) but the vulnerability is built-in to the standard. Once they deviate from the standard, it's no longer 802.11r and doesn't work.

They are not deviating from the standard. KRACK was (theoretically, some made a mess of it) fixed. KRACK relied on a flaw allowing key reinstallation (hence the name!) which was, primarily, an implementation mistake due to an ill-defined standard. Fixing FT did not require deviating from the standard, it required an audit of key handling to prevent such basic mistakes.

What you are saying goes against most manufacturer's recommendations which recommend learning 802.11r switched OFF, even with the latest firmware. Forgive me if I accept the advice given by Cisco and Aruba over your opinion.

This may be the case due to the PMKID attack (which is not KRACK). This is somewhat mitigated by using a reasonable PSK. I do not consider it a significant concern if you use a viable PSK - if you do not, there is no hope anyway. There's also the option not to use PSK.

Please calm down and review the facts rather than knee-jerking. If you recommend disabling FT, that's fine - you can make that recommendation. But please understand why you're making it.

[Halcyon]

You might also considering providing us a rough budget. It's all well and good for people to provide hardware recommendations, however without knowing how much you want to spend, it does make it difficult.

It's basically the case of "how long is a piece of string".

[Kirkhaan]

The total budget I have in mind is < €500.

[Monkeh]

I would suggest keeping your existing Ubiquiti AP and adding more as needed. Don't bother with wifi in the router - it's rarely in a useful location anyway.

E: Oh, hang on, v2? Broadcom. Throw that one away after all.

[Kirkhaan]

E: Oh, hang on, v2? Broadcom. Throw that one away after all.

  

[rdl]

Seeing this thread reminded me that I bought a Ubiquiti Edgerouter a while back. I never really tried it other than making sure it would boot up. Now I see I'll have to spend $80 minimum to add wireless? Wow. The router only cost about $40. Seems expensive.

[Halcyon]

Seeing this thread reminded me that I bought a Ubiquiti Edgerouter a while back. I never really tried it other than making sure it would boot up. Now I see I'll have to spend $80 minimum to add wireless? Wow. The router only cost about $40. Seems expensive.

When you start talking about routers (such as the EdgeRouter), you're getting into enterprise networking territory. Don't forget consumer "routers" are usually 4 appliances in one, a router, basic firewall, wireless access point and modem. When you talk about "routers" its a standalone device that routes traffic between networks. Some routers also have firewall functions, but typically in a commercial installation, the firewall(s) is/are a separate appliance.

Also where some people get caught out stepping up to enterprise Wi-Fi is that most of the time access points aren't autonomous, they require a controller which is either a hardware appliance or a software controller running on a server. Ubiquiti is the same, the access point or points get their config from a controller at boot-up and the controller manages the wireless network. It's far from plug-and-play so those without networking knowledge will find it a challenge. That being said, enterprise wireless radios generally perform much faster, can handle more simultaneous clients, can be far more secure (if you know what you're doing and configure them correctly) and have better antennas which can mean better coverage*.

* Coverage just isn't about bigger antennas and higher transmit power levels, proper channel/band planning is essential. Again, you need to know what you're doing.

[rdl]

I looked into Ubiquiti options and apparently all their wireless devices require this "controller" you mentioned. It's either software or additional expensive hardware. If they have a simple plug in wireless add on, I haven't found it. This pretty much makes Ubiquiti wireless a non-option for me. Seriously, what kind of company has these kind of requirements for software in 2018? Java? Google? Really? I guess I'll have to look into other options.

System Requirements
• Linux, Mac OS X 10.11 (or above), or Microsoft
Windows 7/8/10
• Java Runtime Environment 1.8 or above recommended
• Web Browser: Google Chrome (Other browsers may
have limited functionality .)

[Monkeh]

I looked into Ubiquiti options and apparently all their wireless devices require this "controller" you mentioned. It's either software or additional expensive hardware. If they have a simple plug in wireless add on, I haven't found it. This pretty much makes Ubiquiti wireless a non-option for me. Seriously, what kind of company has these kind of requirements for software in 2018? Java? Google? Really? I guess I'll have to look into other options.

System Requirements
• Linux, Mac OS X 10.11 (or above), or Microsoft
Windows 7/8/10
• Java Runtime Environment 1.8 or above recommended
• Web Browser: Google Chrome (Other browsers may
have limited functionality .)

It doesn't actually have to run continuously for basic operation - despite what Halcyon said, the APs get their basic configuration pushed only once, from there on they operate autonomously. However, statistics collection, guest portals, etc etc, all require an operational controller. At least, that has always historically been the case, I haven't heard of it changing - the APs are liable to boot faster than the controller, so..

You can run the software on something horrendous like a Pi easily enough. Firefox works fine, too.

These are not designed to be single, dumb APs.

[NiHaoMike]

Are you trying to optimize for a few devices or many devices? The former does better with 1 or 2 really good APs, while the latter is best served by using as many APs as will fit into the bandwidth available.

I have experience building a network for cheap smartphones used for cryptocurrency mining. Those phones are typically 2.4GHz only, single stream with just 20MHz support, so the most economical way to optimize performance is to use the existing AP (at the time, a pretty nice dual band, dual stream TEW-811DRU) for one of the 2.4GHz channels and add two cheap APs (a DIR601A1 that was lying around and a DST6501 I got for cheap) for the other two nonoverlapping 2.4GHz channels.

[Halcyon]

I looked into Ubiquiti options and apparently all their wireless devices require this "controller" you mentioned. It's either software or additional expensive hardware. If they have a simple plug in wireless add on, I haven't found it. This pretty much makes Ubiquiti wireless a non-option for me. Seriously, what kind of company has these kind of requirements for software in 2018? Java? Google? Really? I guess I'll have to look into other options.

As I said, this is starting to get into enterprise networking territory. It add complexity but you also get added benefits. If this is kind of stuff is beyond your knowledge, then avoid it.

Part of my job is designing networks for a living. We set this kind of stuff up for clients so they just use it and it works, but there is a lot of planning and expertise that goes into it in the beginning.

It doesn't actually have to run continuously for basic operation - despite what Halcyon said

Once again, you have failed to read and/or understand what I've said. If you read back to what I said, I mentioned the access point or points get their config from a controller at boot-up and the controller manages the wireless network. On other enterprise networks such as Cisco, Motorola and Aruba, the controller continuously monitors the wireless network and makes adjustment in real-time, particularly in relation to channel selection, IDS/IPS etc...

The Ubiquti AP's can run without a controller but only once the initial boot has completed and it has received the config from the controller, from that point they continue running as per the config until such time a reboot happens. However these are not autonomous access points, they are still managed radios. Autonomous access points either store the config themselves and restore it during boot or they feature their own built-in mini-controller of sorts (such as the Arubu IAP series).

[Monkeh]

The Ubiquti AP's can run without a controller but only once the initial boot has completed and it has received the config from the controller, from that point they continue running as per the config until such time a reboot happens. However these are not autonomous access points, they are still managed radios. Autonomous access points either store the config themselves and restore it during boot or they feature their own built-in mini-controller of sorts (such as the Arubu IAP series).

They do store the config themselves.

You can run the controller, configure the APs, shut it down, and power cycle the APs. They will boot and proceed to serve as configured. You can even configure them with an app over bluetooth, and they will again continue to serve as configured.

This assumes, of course, you don't configure them (using the controller, as the phone app shouldn't let you) in such a way they require the controller to be online.

[Halcyon]

The Ubiquti AP's can run without a controller but only once the initial boot has completed and it has received the config from the controller, from that point they continue running as per the config until such time a reboot happens. However these are not autonomous access points, they are still managed radios. Autonomous access points either store the config themselves and restore it during boot or they feature their own built-in mini-controller of sorts (such as the Arubu IAP series).

They do store the config themselves.

You can run the controller, configure the APs, shut it down, and power cycle the APs. They will boot and proceed to serve as configured. You can even configure them with an app over bluetooth, and they will again continue to serve as configured.

This assumes, of course, you don't configure them (using the controller, as the phone app shouldn't let you) in such a way they require the controller to be online.

The iOS/Android mobile application still acts as a controller however its severely limited in what you can do with it (probably on purpose). UBNT call this "standalone mode". I could be wrong (as I haven't used this for a while) but as far as I'm aware, only a single access point can be configured and managed this way. It's not recommended by UBNT but it's an option for those who want a *really* basic set up but still use Ubiquiti hardware.

Although as basic as it is, it's still not something I would recommend for a home user who has no networking knowledge and just want something "plug and play". The best advice to home users who want to stick with an all-in-one consumer box is physically position it in the most central place within the home if possible and don't hide it away in a cupboard. You might also want to look at something like the Ubiquiti AmpliFi or Linksys Velop mesh systems. Avoid "dumb" Wi-Fi repeaters as they generally just add to co-channel interference, degrading performance.

[Monkeh]

The Ubiquti AP's can run without a controller but only once the initial boot has completed and it has received the config from the controller, from that point they continue running as per the config until such time a reboot happens. However these are not autonomous access points, they are still managed radios. Autonomous access points either store the config themselves and restore it during boot or they feature their own built-in mini-controller of sorts (such as the Arubu IAP series).

They do store the config themselves.

You can run the controller, configure the APs, shut it down, and power cycle the APs. They will boot and proceed to serve as configured. You can even configure them with an app over bluetooth, and they will again continue to serve as configured.

This assumes, of course, you don't configure them (using the controller, as the phone app shouldn't let you) in such a way they require the controller to be online.

The iOS/Android mobile application still acts as a controller however its severely limited in what you can do with it (probably on purpose). UBNT call this "standalone mode". I could be wrong (as I haven't used this for a while) but as far as I'm aware, only a single access point can be configured and managed this way. It's not recommended by UBNT but it's an option for those who want a *really* basic set up but still use Ubiquiti hardware.

It only configures it, though. Once you close the app there's nothing there. Reboot away - the AP is configured. This is no different with a normal controller.

[cdev]

Lots of wifi security info here: https://www.krackattacks.com and https://www.mathyvanhoef.com/p/publications.html