macOS Wi-Fi Roaming

One of the nice things about Intel wireless chipsets is that the drivers expose a lot of controls to help tune the chipset’s operation. One of my favorite of these controls is “Prefered Band,” which I usually adjust to instruct the chipset to prefer the 5 GHz band over the 2.4 GHz band. There are some other useful controls like “Roaming Aggressiveness” and you can also enable Fat Channel Intolerance if a neighbor is rudely using 40 MHz of spectrum in 2.4 GHz.

intel_driver

Although macOS has many advantages over Windows when it comes to Wi-Fi, such as the ability to natively do packet captures with the internal chipset, macOS doesn’t have the same level of customization as a Windows machine with an Intel chipset. And my experience has been that Mac clients don’t roam particularly well. Too often they are “sticky clients” and you need to disable/enable Wi-Fi on them to get them to associate with a better BSS.

Here’s a screenshot for a MacBook Air which wouldn’t roam away from a BSS whose RSSI has fallen to -80 dBm, while the laptop was only able to transmit at MCS 0, 7 Mbps. However there was another BSS in the -60’s which would have allowed for much better Wi-Fi performance.

macos_wifi
Why is the native macOS Wi-Fi menu showing a full signal with -80 dBm RSSI and MCS 0? Wi-Fi Signal tells the real story.

In 2016 Apple published a webpage that explains how macOS makes roaming decisions and what roaming features it supports. This is very helpful and I wish other manufacturers would do the same. The algorithms that control client roaming are usually a black box, so Wi-Fi engineers have make a lot of assumptions about them when designing WLAN’s for clients that require efficient roaming. That said, while Apple says Macs should usually roam at -75 dBm, that doesn’t match my experience. Sometimes Macs are just sticky.

One reason for this is that once the roaming threshold is crossed, a Mac will only roam to a BSS that is 12 dBm louder than the current BSS, which would require a roaming candidate BSS to have an RSSI of -63 dBm or better before roaming will occur at -75 dBm. There doesn’t appear to be any way to modify this value.

Enabling 802.11k or 802.11v won’t help because macOS does not yet support those features, although they don’t prevent Macs from using an SSID that has them enabled. 802.11k and .11v are supported in Windows 10, however, if the wireless adapter supports those features.

There is an old plist that once controlled “opportunistic” roaming behavior, which I suspect meant roaming above -75 dBm RSSI.

/Library/Preferences/com.apple.airport.opproam

…which has these defaults in macOS 10.12 Sierra:

{
    deltaRSSI = 10;
    disabled = 0;
    useBonjour = 0;
    useBroadcastBSSID = 1;
}

That looks promising, however, this plist hasn’t been used by macOS since macOS 10.10 Yosemite. It’s ignored by the OS now, and when it was utilized, it wasn’t intended to be user-editable, so changes were likely to be overwritten by the OS.

So if you are an enterprise with a fleet of Macs to manage and you run into sticky client issues, consider infrastructure features like Cisco’s Optimized Roaming or Aruba ClientMatch to force better roaming behavior among these clients.

To observe roaming behavior on a Mac, I recommend WiFi Signal from Adrian Granados. It can be setup to generate macOS notifications when roaming events occur or the RSSI of the AP drops below a certain threshold.

wifi-signal-notifications

Advertisements

School 1:1 Program WLAN Design Considerations

The design of a WLAN to accommodate a school’s 1:1 program can make or break the entire enterprise. A poorly designed WLAN presents connectivity issues, bandwidth issues, co-channel contention, and RF utilization problems that distract end-users from classroom activities and results in a loss of trust in the technology. Similarly, clients with substandard Wi-Fi chipsets will also compromise WLAN performance.

These are some of the important considerations I’ve learned when designing and operating a WLAN to support a school’s 1:1 program.

Wireless LAN

Key points to consider when designing a high-density WLAN to support a 1:1 program:

  • 802.11ac is highly desirable, 802.11n is workable and a minimum requirement
  • Do a site survey to determine optimal AP placements, but design for capacity, not solely coverage
  • Evaluate your switching capacity, including PoE budgets, for AP backhaul
  • Establish client SLA’s before designing the WLAN
  • 5 GHz radios are required
  • DFS channels are required for wide channels or very-high density
  • 2.4 GHz becomes a junk band in high density. Use it only for guest/BYOD clients.
  • Use band-steering to move clients to the 5 GHz spectrum
  • Use the entire 5 GHz spectrum everywhere, and choose channel bandwidths to prevent cell overlap.
    • 80 MHz channels in coverage-areas
    • 40 MHz channels in high-density areas like classrooms
    • 20 MHz channels in really high-density areas such as multi-story classroom layouts
  • Disable low data-rates, all the way up to 24 Mbps. Experiment with going higher.
  • Reduce maximum AP radio power to limit cell sizes
  • Reduce AP radio receive sensitivity to prevent clients at the edge of the cell from associating
  • Use load balancing techniques to spread clients evenly among AP’s
  • Limit SSID’s to as few as possible, generally no more than three. Try this:
    • 1 SSID with WPA2-Enterprise security for school and BYOD devices
      • Use AAA override/dynamic profile assignment (whatever your vendor calls it) to assign security policies, access control, VLAN’s, and QoS policies via RADIUS attributes
    • 1 SSID with no security for guest access
  • Only use WPA2-Enterprise 802.1X authentication. WPA-PSK is a nightmare if you ever need to change the password.
  • Use an MDM solution to distribute Wi-Fi credentials
  • Rate-limit guest and BYOD clients
  • Use QoS to deprioritize traffic from guest and BYOD clients
  • Use layer 7 QoS to deprioritize/rate-limit bandwidth hogs that are not time sensitive including
    • Mac OS, iOS, Chrome OS, and Windows software updates
    • Dropbox, iCloud, and Skydrive syncing
    • Site-specific background data hogs such as an enterprise AV deployment, WSUS server, etc.
  • Track the applications used on the WLAN and use layer 7 QoS to deprioritize/rate-limit bandwidth hogs that are time sensitive, but are only used for recreational purposes on the WLAN.
    • Netflix, Pandora, Grooveshark, etc.

Should time allow, many of these points will become blog posts of their own.

Client Devices

For all of this to work, client devices must meet these requirements. Cheap and used devices rarely meet these specifications. Choose carefully. Don’t compromise.
  • 802.11n minimum, 802.11ac desired
  • The more spatial-streams, the better
  • 802.1X support
  • MDM support
  • 5 GHz band support
  • DFS channel support
Unfortunately many device manufacturers limit the Wi-Fi specs they publish to simply “802.11n” or “802.11ac.” Tracking all of this down is often only possible through testing a device in-person, especially DFS support.