Fixing WiFi roaming in macOS

I recently extended my WiFi network coverage with a TP-Link EAP225 v3 access point in the garage, connected via an ethernet cable to the router in my office. The garage and my office are at opposite corners of the house, so this combination should provide excellent coverage overall.

This blog post is reminder to myself about the problems that can prevent devices from roaming between the two WiFi access points based on whichever has a stronger signal.

macOS in particular had a hard time switching to the stronger signal, and the cause turned out to be a slight discrepancy between the security protocols supported by the two access points. Despite having the same SSID and password, if the security protocols are not identical, the implicit roaming support in macOS would not function properly.

The most helpful tool to diagnose this issue was the command-line airport utility, which is located in /System/Library/PrivateFrameworks/Apple80211.framework/Resources

Running “airport -s” from this location will dump out all the SSIDs found, as well as their security settings. Any discrepancies need to be fixed…in my case the EAP225 was configured to support an extra protocol (TKIP) in addition to EAS. TKIP is less secure anyway, so disabling it not only solved the roaming problem but probably increased security as well.


Revolution in low-power NAS

Even though I’m a Mac user at home, I hadn’t been paying attention to a revolutionary step forward in lowering power consumption.

I’m speaking of the “Wake on Demand” feature in Snow Leopard and Airport routers.  This is a combination of router + OS trickery that has great potential for allowing machines to go to sleep (i.e. 1w – 3w power usage), while the router acts as a proxy for the sleeping machines and acts as a proxy for the sleeping server.  If another machine attempts to access the server, the router will send the magic WakeOnLan packet (or WakeOnWifi equivalent) to the server so that it can handle the request.

I haven’t figured out how exactly it works, but most attempts to connect to a sleeping Mac via either SSH connections, VNC, SMB, or AFP will trigger the wakeup.  The underlying infrastructure is Bonjour/ZeroConf based, and I think the new router “sleep proxy” could easily be integrated into OpenWRT or other firmware, but more interesting is how Apple might have had to tweak their OS to get Bonjour involved in things like opening an SSH connection to another machine.  For example, I would have thought vanilla OpenSSH would use raw sockets instead of a Bonjour API, so I wonder whether Apple has had to modify all of its common client software packages to play well with this infrastructure?

If this can be spread to other routers and NAS operating systems, it would bypass the need to optimize idle power consumption with exotic Atom-based motherboard, etc.  A low-cost Core i3 with mainstream H55 motherboard already beats or gets very close to an Atom board in terms of idle consumption, but actually letting your server go to sleep is a order of magnitude improvement over either.

More info here: