My TP-Link EAP653 (ad: available on Amazon) Wi-Fi access point (AP) has some features that don’t work well together. Who would have thought that its proprietary extensions to the Wi-Fi standard would cause compatibility issues with clients?
I’ve configured the AP to power down the fast 5 GHz radio at night to reduce its power consumption. The 5 GHz band uses less power than 2,4 GHz (faster means shorter transmission time). However, not all devices are compatible with the former. The power savings is about the same during off-peak hours anyway. Clients should fall back to the slower 2,4 GHz network and remain connected throughout the night.
However, the AP’s proprietary band steering
feature isn’t aware of its power-saving radio scheduling feature. This setup interaction results in frustrated client devices that don’t understand why they can’t connect to the 2,4 GHz network while the 5 GHz network is unavailable.
Wi-Fi band steering is a non-standard extension of the Wi-Fi standard (IEEE Standard 803.11). Other vendors use other names for the same feature, including “prefer 5 GHz” and “client steering”. As such, the exact technique deployed varies from vendor to vendor. The gist of band steering is that the AP will pretend that the 2,4 GHz network is unavailable to steer clients over to the faster and less congested 5 GHz network. The AP will attempt to detect 5 GHz-capable clients and may choose to respond slower (or not at all) to connection requests on the 2,4 GHz network.
Band-steering requires a dual- or tri-band network setup that operates with the same SSID and security settings on all bands. In 2,4/5 GHz dual-band networks, clients will normally automatically decide whether to connect to the 2,4 GHz or 5 GHz network. The 2,4 GHz band offers increased range and coverage, but at lower data transmission speeds than the 5 GHz band. Clients generally prefer to join the 2,4 GHz network but might decide to use the 5 GHz network if conditions are good.
TP-Link’s implementation of band steering drops the connection on the 2,4 GHz band during the AP association process immediately after it has been established. This design lets it get the client device’s real hardware (“MAC”) address. As opposed to the randomized privacy-preserving MAC addressed that might be used earlier in the connection process. The AP counts the number of connection attempts from the same MAC address to the 2,4 GHz band. If the client doesn’t get the hint and keeps attempting to connect to the 2,4 GHz band, the AP will allow the connection after 10 failed attempts. The failure counter is reset periodically.
Android clients also count the number of failed connection attempts to an AP. They assume the Wi-Fi password must be incorrect after five consecutive failed attempts. Android then temporarily disables the SSID; which is shared among the different bands in a multi-band configuration. It also prompts the user to correct what it believes is an incorrect Wi-Fi password.
Users will need to quickly type the correct password five times — without loosing faith that they’re indeed typing it correctly every time — to successfully join the network. This is a terrible user-experience that is bound to result in confusion, frustration, and support tickets.
To be clear, the AP never told the client there was anything wrong with the password. The client passed the authentication process and gets rejected during the following link association process. I can only assume Android adopted this error handling for compatibility with some unusual and buggy APs. At any rate, the user will surely be frustrated by being told the correct password to their Wi-Fi network is incorrect when that’s not the issue.
I’m surprised that TP-Link didn’t discover this problem with Android clients and set a lower “max failures” value by default. That this went unnoticed suggests to me that TP-Link only tested that the feature works as it expected under ideal conditions. It evidently didn’t bother to verify that the feature failed gracefully with clients running the world’s most popular consumer operating system.
You can fix this problem by either disabling band steering or power-scheduling on your AP. You can also leave both features enabled and change the AP’s band steering logic to give up after four errors instead of ten. The relevant setting in TP-Link products is found under Wireless: Band Steering: Max Failures.
Changing this setting fixes the compatibility issue with Android clients. Other devices may still experience faulty behavior depending on their network reconnection algorithms.
You could also disable the 2,4 GHz band instead of the 5 GHz band radio. However, even brand-new devices aren’t guaranteed to be equipped with a 5 GHz-capable radio. Some clients on your network, especially cheaper ones, will likely drop off the network if only the 5 GHz band remains available.
The proper fix is for TP-Link to automatically disable the band steering feature when the 5 GHz network is powered off. I’m guestimating that TP-Link is only missing about ten lines of code. It shouldn’t be difficult to patch. Alternatively, TP-Link could allow its customers to schedule the band steering feature on/off as well as the radio power schedule. At the very least, the AP should warn users about incompatible settings when enabling both power scheduling and band steering.
TP-Link has needlessly made its band steering feature a checkbox that can potentially break the product. A few conditional checks in the code could have safeguarded it from misconfiguration and bad interactions with other features. It’s incredibly lazy programming to blindly trigger the band steering logic on the 2,4 GHz band without first verifying that a suitable 5 GHz band is there to receive the client.