MacInTouch Amazon link...

AirPort issues/alternatives

Channels
Apple, Security, Products


Ric Ford

MacInTouch


Ric Ford

MacInTouch
Which version of HomePlug did they support, and what kind of performance were you seeing?
Here are the devices:
I have no idea about HomePlug. Performance was below AmpiFi HD levels but not as horrendous as AirDrop, for example. I didn’t log the numbers
I changed things up and checked performance anew with the powerline adapters: about 27 Mbps down, 26 Mbps up, which is near the max for this FiOS service and what I'm getting from the AmpliFi HD wireless set-up.

This was on a different a/c circuit (possibly closer to the router) and direct into an iMac 5K Ethernet port. The other powerline adapter is plugged directly into the Verizon FiOS router. (No Thunderbolt docks and adapters involved this time.)
 


I changed things up and checked performance anew with the powerline adapters: about 27 Mbps down, 26 Mbps up, which is near the max for this FiOS service and what I'm getting from the AmpliFi HD wireless set-up.
Yeah, those are HomePlug AV2, which is the latest tech for that, so I would expect high performance from them. You could test the performance of just the HomePlug link by putting two computers on either end and running something like iPerf.

In general, I'd prefer wired backhauls for WiFi access point deployment over wireless backhauls. Even something like HomePlug would be more consistent and less prone to interference and other variability than wireless.
 


Ric Ford

MacInTouch
Yeah, those are HomePlug AV2, which is the latest tech for that, so I would expect high performance from them. You could test the performance of just the HomePlug link by putting two computers on either end and running something like iPerf. In general, I'd prefer wired backhauls for WiFi access point deployment over wireless backhauls. Even something like HomePlug would be more consistent and less prone to interference and other variability than wireless.
Thanks for the reminder about iPerf. As far as powerline adapters and Ethernet go, my main concern is electrical problems, particularly the effects of lightning storms. Years ago, a local Mac repairman I trusted told me that most of their repairs were for that problem. I don't have any additional data about that issue, but I also had some troublesome issues with Ethernet hubs/switches, and I've been wary of the issue ever since it came up.
 


When we moved house about a year ago, I looked for a simple enough mesh system for the family to use. I was happy with my mish-mash of routers and access points and what have you from Asus and Apple. But the family was always confused which access point to use and why this one is stronger that that one and so on.

So eventually I decided on Google Wifi. All basically works, but if I take some of the server stuff off it and just have it wired, the Google-connected devices can't see them any more.

This is a bit of a mess, I can't figure out how to get its routing sorted out. All I have is a little phone app that gives me the basics. I'd like to hear from anybody who has mastered this better... thanks.
 


So eventually I decided on Google Wifi. All basically works, but if I take some of the server stuff off it and just have it wired, the Google-connected devices can't see them any more.
Google WiFi wants to be your main router and cannot do all of its mesh magic unless everything is "downstream" from the "master" Google WiFi device.

If you plug your modem into the WAN port on the "master" device and run all your wired stuff connected to the LAN port on the "master" device, you can interact between wired and wireless (my wired printer can be seen by my Google-connected wireless devices for example).

If your ISP provides you a modem with a router and a switch with multiple ports, and you cannot get that modem to just act as a bridge to let Google WiFi be the router, you might be forced to connect the Google WiFi in such a way that you get a "double NAT" situation. Generally this will still work fairly well, but it becomes challenging to set up incoming connections to devices on your local network from devices on the Internet at large.

If you directly connect other devices to the ISP's modem/router/switch, devices downstream of the Google WiFi will not be able to contact them - the Google WiFi devices basically create a separate LAN inside the LAN made by the ISP's modem/router/switch.
 


... So eventually I decided on Google Wifi. All basically works, but if I take some of the server stuff off it and just have it wired, the Google-connected devices can't see them any more....
Google has some documentation on how to hardwire their mesh points. You have to first initialize them with no other devices hooked to the ethernet ports (except the first, "master"/"primary" one that needs to be connected to the Internet on the WAN (globe icon) port).

In the diagram on that page is an example called "Include a switch downstream of the Primary Wifi point". Where the downstream "Mesh WiFi point" is hanging of the switch, you could optionally place a hardwired 'server' system also. If you need multiple Ethernet ports downstream from the primary WiFi device, you can add a switch to one of the later mesh points also (whether it is wired or not). The Google WiFi devices that have been configured to not be in primary mode can use either of those ports to connect devices. (If only one, you don't need a switch.)

A simple unmanaged switch will do. I've used some Netgear ones. For example, if have 2-3 servers and/or streaming media-consuming systems to wire up, then something like a
GS305 will do.
All I have is a little phone app that gives me the basics.
The phone app is primarily just going to configure and manage the Google WiFi devices. How the data is routed via wires or radio, the "mesh smarts" will just do. The primary mesh point, though, will set up a firewall to everything on the "other side" of the WAN port (going toward the Internet). So, if you want your stuff to 'see' each other, they should be "downstream" of that single, specific port.
 


Google has some documentation on how to hardwire their mesh points. You have to first initialize them with no other devices hooked to the ethernet ports (except the first, "master"/"primary" one that needs to be connected to the Internet on the WAN (globe icon) port).
Nice to know Google has built in, and documented, this flexibility. But how many of us really want all of our home Internet traffic, even our home LAN traffic, going through devices designed and made by Google?

Google may swear, as it does with Gmail, that it never "reads" the contents, but the only reason it's in the business is to apply data science to the huge volume of traffic, in order to drive its primary business, selling ads. And they have a sordid record when it comes to actually telling the truth about what they do and don't look at.
#security #privacy #Google
 


Nice to know Google has built in, and documented, this flexibility. But how many of us really want all of our home Internet traffic, even our home LAN traffic, going through devices designed and made by Google?
There was a time when I'd have been here to defend Google, but that ended when I did a Wikipedia search for a reference to Trotsky's phrase "dung heap of history" (there are varied translations). (1) I was "on" Wikipedia, not Google Search; (2) I did use the GBoard keyboard on an Android phone. Almost immediately thereafter I started finding suggested phrases related to Communism in the varied places Google could put them...

But Google aside, most of the "mesh" routers now seem to be cloud-managed, connected, subscription services passing through the seller. Amazon bought Eero, and it's now integrated with Alexa. I'm not sure how it is possible to characterize differences in the way Google and Amazon monitor customers, but I know Amazon's watching everything it can and keeping records a very long time.
 


But how many of us really want all of our home Internet traffic, even our home LAN traffic, going through devices designed and made by Google? Google may swear, as it does with Gmail, that it never "reads" the contents, but the only reason it's in the business is to apply data science to the huge volume of traffic, in order to drive its primary business, selling ads.
Google Cloud services and hosting is about a $4B/year business. Routing over networks dynamically "thrown" at them is something they do at a large scale on a daily basis for money, not ads.

Yes, ads is a bigger business, but this one is quite large itself. The home router stuff allows them to do things at a different scale (and probably learn some things along the way that they can cross-pollinate). The basic coupling is: if people aren't online, they can't see online ads, so an indirect synergy. But if your LAN is pinging their ad servers, what is actually "new" that they are sniffing out? You can opt out of features and data sharing and still get connected to the internet with the Wi-Fi system.
And they have a sordid record when it comes to actually telling the truth about what they do and don't look at.
I'm pretty sure Google sells this product in the EU (they are in the UK and German Amazon stores) and hence is covered by GPDR. These new "opt out" screens show up before they turn on different aspects of the system. It is highly likely that Google's Wi-Fi devices are in compliance with GPDR.

These mesh systems that automagically do dynamic configuration are going to need data to learn and get better from — kinds of devices and aggregate bandwidth between is going to be slurped up by anyone trying to get better and smarter at doing the set-up. Most users don't want high detail and long set ups.
 


Google Cloud services and hosting is about a $4B/year business. Routing over networks dynamically "thrown" at them is something they do at a large scale on a daily basis for money, not ads. Yes, ads is a bigger business, but this one is quite large itself. The home router stuff allows them to do things at a different scale (and probably learn some things along the way that they can cross-pollinate). The basic coupling is: if people aren't online, they can't see online ads, so an indirect synergy. But if your LAN is pinging their ad servers, what is actually "new" that they are sniffing out? You can opt out of features and data sharing and still get connected to the internet with the Wi-Fi system. I'm pretty sure Google sells this product in the EU (they are in the UK and German Amazon stores) and hence is covered by GPDR. These new "opt out" screens show up before they turn on different aspects of the system. It is highly likely that Google's Wi-Fi devices are in compliance with GPDR.
I hear you but (1) Google has a repulsive history of lying, getting caught, paying (for them) a nominal penalty, and then finding other ways of gathering ad-actionable data, and (2) $4B is a measurable, but small part of Google's > $100B annual revenue. I trust them about as far as I could throw their corporate headquarters.

I have little doubt Google is currently violating the GPDR, in what they believe to be subtle ways, simply on the basis of track record: the toxic Silicon Valley culture of money = superiority in judgment (any contrary facts notwithstanding).

That said, Google operates a reliable (at least as reliable as any other I know of) name service.
 


Ric Ford

MacInTouch
You could test the performance of just the HomePlug link by putting two computers on either end and running something like iPerf.
OK, just trying to get up to speed with iPerf, I find that I can open two Terminal windows on my primary Mac and have a bit of fun.

Set up a server in one window:
Bash:
iperf -s
Run a client in a second window:
Bash:
iperf -c localhost -i1
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size:  144 KByte (default)
------------------------------------------------------------
[  5] local 127.0.0.1 port 50200 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0- 1.0 sec  3.03 GBytes  26.0 Gbits/sec
[  5]  1.0- 2.0 sec  3.02 GBytes  25.9 Gbits/sec
[  5]  2.0- 3.0 sec  3.01 GBytes  25.9 Gbits/sec
[  5]  3.0- 4.0 sec  3.04 GBytes  26.1 Gbits/sec
[  5]  4.0- 5.0 sec  3.04 GBytes  26.1 Gbits/sec
[  5]  5.0- 6.0 sec  3.05 GBytes  26.2 Gbits/sec
[  5]  6.0- 7.0 sec  3.09 GBytes  26.5 Gbits/sec
[  5]  7.0- 8.0 sec  3.06 GBytes  26.3 Gbits/sec
[  5]  8.0- 9.0 sec  3.04 GBytes  26.1 Gbits/sec
[  5]  9.0-10.0 sec  3.02 GBytes  25.9 Gbits/sec
[  5]  0.0-10.0 sec  30.4 GBytes  26.1 Gbits/sec
As a comparison, Geekbench 4 said:
Memory Bandwidth: 23.6 GB/sec [i.e. ~ 188.8 Gbits/sec]​
How about connecting the MacBook Pro over WiFi to the Intel NUC via the AmpliFi HD mesh router and MeshPoint access point from opposite ends of a house?
Bash:
iperf -c <NUC> -i1
------------------------------------------------------------
Client connecting to <NUC>, TCP port 5001
TCP window size:  129 KByte (default)
------------------------------------------------------------
[  4] local <MacBook Pro> port 51041 connected with <NUC> port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec  9.38 MBytes  78.6 Mbits/sec
[  4]  1.0- 2.0 sec  10.1 MBytes  84.9 Mbits/sec
[  4]  2.0- 3.0 sec  10.2 MBytes  86.0 Mbits/sec
[  4]  3.0- 4.0 sec  9.00 MBytes  75.5 Mbits/sec
[  4]  4.0- 5.0 sec  9.88 MBytes  82.8 Mbits/sec
[  4]  5.0- 6.0 sec  9.88 MBytes  82.8 Mbits/sec
[  4]  6.0- 7.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  7.0- 8.0 sec  9.88 MBytes  82.8 Mbits/sec
[  4]  8.0- 9.0 sec  9.50 MBytes  79.7 Mbits/sec
[  4]  9.0-10.0 sec  10.4 MBytes  87.0 Mbits/sec
[  4]  0.0-10.0 sec  99.5 MBytes  83.3 Mbits/sec
That's about triple the speed of the Internet connection, in this case.
 


Ric Ford

MacInTouch
How about connecting the MacBook Pro to the Intel NUC over the AmpliFi HD router and MeshPoint from opposite ends of a house?
Let's turn off WiFi on the MacBook Pro, connect a Thunderbolt-Ethernet adapter, connect that to a powerline adapter, which connects to another powerline adapter over home wiring, which connects to the FiOS router via Ethernet, which is connected via Ethernet to the Intel NUC. Test the MacBook Pro as a server from the NUC as a client:
Bash:
perf -c <MacBook Pro> -i1
------------------------------------------------------------
Client connecting to <MacBook Pro>, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local <NUC> port 41344 connected with <MacBook Pro> port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  7.62 MBytes  64.0 Mbits/sec
[  3]  1.0- 2.0 sec  6.75 MBytes  56.6 Mbits/sec
[  3]  2.0- 3.0 sec  7.25 MBytes  60.8 Mbits/sec
[  3]  3.0- 4.0 sec  6.88 MBytes  57.7 Mbits/sec
[  3]  4.0- 5.0 sec  7.12 MBytes  59.8 Mbits/sec
[  3]  5.0- 6.0 sec  7.00 MBytes  58.7 Mbits/sec
[  3]  6.0- 7.0 sec  7.00 MBytes  58.7 Mbits/sec
[  3]  7.0- 8.0 sec  6.88 MBytes  57.7 Mbits/sec
[  3]  8.0- 9.0 sec  7.25 MBytes  60.8 Mbits/sec
[  3]  9.0-10.0 sec  7.00 MBytes  58.7 Mbits/sec
[  3]  0.0-10.0 sec  70.8 MBytes  59.3 Mbits/sec
Swap roles; the NUC is now the server with the MacBook Pro as its client.
Bash:
iperf -c <NUC> -i1
------------------------------------------------------------
Client connecting to <NUC>, TCP port 5001
TCP window size:  129 KByte (default)
------------------------------------------------------------
[  4] local <MacBook Pro> port 51884 connected with <NUC> port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec  11.1 MBytes  93.3 Mbits/sec
[  4]  1.0- 2.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  2.0- 3.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  3.0- 4.0 sec  11.1 MBytes  93.3 Mbits/sec
[  4]  4.0- 5.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  5.0- 6.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  6.0- 7.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  7.0- 8.0 sec  11.1 MBytes  93.3 Mbits/sec
[  4]  8.0- 9.0 sec  11.1 MBytes  93.3 Mbits/sec
[  4]  9.0-10.0 sec  11.2 MBytes  94.4 Mbits/sec
[  4]  0.0-10.0 sec   112 MBytes  93.8 Mbits/sec
Swap out the FiOS router and replace it with the AmpliFi HD router as our Ethernet hub (Ethernet to NUC and Ethernet over powerline adapters to MacBook Pro).
Bash:
iperf -c <NUC> -i1
------------------------------------------------------------
Client connecting to <NUC>, TCP port 5001
TCP window size:  129 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec  9.75 MBytes  81.8 Mbits/sec
[  4]  1.0- 2.0 sec  10.2 MBytes  86.0 Mbits/sec
[  4]  2.0- 3.0 sec  10.8 MBytes  90.2 Mbits/sec
[  4]  3.0- 4.0 sec  10.6 MBytes  89.1 Mbits/sec
[  4]  4.0- 5.0 sec  11.6 MBytes  97.5 Mbits/sec
[  4]  5.0- 6.0 sec  10.8 MBytes  90.2 Mbits/sec
[  4]  6.0- 7.0 sec  11.9 MBytes  99.6 Mbits/sec
[  4]  7.0- 8.0 sec  11.5 MBytes  96.5 Mbits/sec
[  4]  8.0- 9.0 sec  12.6 MBytes   106 Mbits/sec
[  4]  9.0-10.0 sec  11.6 MBytes  97.5 Mbits/sec
[  4]  0.0-10.0 sec   111 MBytes  93.4 Mbits/sec
So...
  • Networking performance is very, very fast when the network consists only of a single Mac. :-)
  • Wired LAN performance over powerline adapters is a lot faster than WiFi LAN performance. (Todd was right.)
  • WiFi LAN performance (AmpliFi HD mesh) is a lot faster than Internet performance when FiOS is limited to 30Mbps (so WiFi doesn't limit the Internet in this case).
  • Mac performance as a server may be worse than Linux performance as a server.
 



I have a weird tale of two AirPort base stations and USB drives. One of them is my home one (2.5", bus-powered drive), the other at my mother's (3.5" drive housed in a OWC external enclosure). Both drives have the same purpose, i.e. to serve up Sonos content. The drive at home has worked flawlessly, and both base stations were configured to use account passwords. Prior to AirPort 7.9.1 firmware, the drive at mom's worked OK, but post-update, the AirPort Extreme and the disk drive no longer play nice. Instead, mom's base station power cycles almost the second it has booted.

Remove the USB connection or turn the external drive off, and the issues go away. Thinking it might be a bad AirPort access point, I swapped AirPort base stations, but the problem persists - endless boot cycle. I reckon my nest step is to also swap the cable and the disk drive? Anyone else have the same issue or suggestions?
 


Speaking of old systems, I figured out the issue with this one. It's not the airport, USB cable, or hard drive: it's the enclosure for the hard drive.

I'd put a ton of data on the drive previously and could hear it spin up. However, I had done all that at home before swapping out the drive in moms enclosure and coincidentally also upgrading the airport firmware. That's when the endless reboots started happening. But as the say, correlation is not causation!

Troubleshooting further, once I tried to connect the drive to my Mac, it wouldn't mount. Then, seeing that the replacement drive is a 3TB model and the old one was a 2TB, a light bulb went off and I looked at the enclosure.

Sure enough, that OWC Mercury Elite Pro is old enough to still feature the 5-pin DIN power supply and only offer USB 2... and unlike later models still used the 4 torx button bolts to hold it together. This enclosure likely can only handle up to 2TB drives!

So, time for a new enclosure or a bus-powered drive. But, I was not happy with the failure mode on the part of the airport. A confused USB drive should not be able to take down a airport base station and put it in a perpetual reboot cycle...
 


In Tuesday October 15 MacInTouch news:
AirPort Utility for macOS is up to at least 6.3.7, from 2017, while the newest Windows version found was Version 5.6.1 from 2012. AirPort firmware updates contain critical security patches from time to time.
I retired my AirPort Extreme early this year, but the macOS AirPort Utility still resides on my computer (just in case). The version I have is 6.3.9, from August 17, 2018, and Info shows a "modified" date of October 8, 2019.
 


Ric Ford

MacInTouch
I retired my AirPort Extreme early this year, but the macOS AirPort Utility still resides on my computer (just in case). The version I have is 6.3.9, from August 17, 2018, and Info shows a "modified" date of October 8, 2019.
Thanks for that info! I checked my macOS Sierra system, checked Apple's idiotically dysfunctional "downloads" page, found nothing at the Mac App Store, did a search of Apple's website, and jumped through a few other hoops but missed that update. What macOS version are you running? Any idea where and when you actually got that version?
 


Thanks for that info! I checked my macOS Sierra system, checked Apple's idiotically dysfunctional "downloads" page, found nothing at the Mac App Store, did a search of Apple's website, and jumped through a few other hoops but missed that update. What macOS version are you running? Any idea where and when you actually got that version?
I was on Sierra at that time (finally moved to Mojave just this past week!). Don’t remember if the update was through a notification via App Store / Software Update or, generated by the router, as done for firmware updates, nor do I recall the reason given for it. The October 2018 ”modified” date could have been a background stealth update. Might find some trail breadcrumbs if I pulled up and started poking through Time Machine.
 


I was on Sierra at that time (finally moved to Mojave just this past week!). Don’t remember if the update was through a notification via App Store / Software Update or, generated by the router, as done for firmware updates, nor do I recall the reason given for it. The October 2018 ”modified” date could have been a background stealth update. Might find some trail breadcrumbs if I pulled up and started poking through Time Machine.
If you have launched an earlier version of Airport Utility it will notify of upgrade availability. If you want to delete and start over, you can download 6.3.1 from Download AirPort Utility 6.3.1 for Mac that currently downloads a pre-Catalina version which should be upgradable from there.

My current Airport Utility Version 6.3.9 (639.9) on Mojave is of equally determinate provenance.

I have not previously looked at the Airport Utility version on any Catalina system. My Catalina Beta system, created by erase and install of Catalina 10.15 Beta in June, has no Mojave history and is now running 10.15.1 (Build 19B68f). Airport Utility reports 6.3.9 (639.13).

The two Airport Utility 6.3.9 builds, 639.9 and 639.13 are not interchangeable. This is probably due to the differing path structures that came with Catalina's dual volume configuration. The Catalina version also adds an Airport Analytics... item in the Base Station menu.
 


Thanks for that info! I checked my macOS Sierra system, checked Apple's idiotically dysfunctional "downloads" page, found nothing at the Mac App Store, did a search of Apple's website, and jumped through a few other hoops but missed that update. What macOS version are you running? Any idea where and when you actually got that version?
I'm on Mojave with AirPort Utility version 6.3.9, modification date of 8/2/19. I have things set for manual update. Checking System Report\Software\Installations, I see that macOS 10.14.6 was installed on that date. I wonder if the Airport Utility version was part of that update? It could also have been coincidence, or I did other housekeeping items at the same sitting.
 


Ric Ford

MacInTouch
If you have launched an earlier version of Airport Utility it will notify of upgrade availability.
I have macOS Sierra, all updated with everything, and my AirPort Utility is Version 6.3.7. The app preferences are set to check for updates, but no updates are shown, even though your Mojave version is newer.

I followed up by email with Jim, who provided more version details:
The availability of an Airport Utility update is a function of the host OS. Checking several machines which are at their latest version of the installed OS:
macOS VersionAirPort Utility Version
Snow Leopard5.6.1 (561.3)
Sierra6.3.7 (637.6)
High Sierra6.3.8 (638.9)
Mojave6.3.9 (639.9)
Catalina6.3.9 (639.13)
 
Last edited:


I have two AirPort Extreme 802.11ac base stations, but I can't wirelessly extend the main AirPort's network. The AirPorts are close enough that reception is not an issue.

This weekend I tried extending a client's AirPort Extreme 802.11ac using their older 802.11n that the ac model replaced. I had the exact same errors I'm getting with my AirPorts. (The only functional difference is their network is closed/hidden, mine is not.)

My AirPort is setup with Bridge Mode and uses Timed Access. Internet is DHCP. Configure IPv6 is Automatically. The 5GHz network has a separate name.

After doing a factory reset on the extender I used AirPort Utility on a Mojave Mac with the 802.11ac base station. I also use my iPhone's Settings > Wi-Fi. I also tried an El Capitan Mac's AirPort Utility. Regardless of what sets up the extender, it says there's no Internet Connection (and hence no DNS servers).

I know the AirPorts are talking to each other, because when I added each AirPort's two radio MAC addresses to the Timed Access list on one AirPort, the entries show up on the other.

Turning off the separate 5GHz network name didn't fix it. I exported the extender's configuration and saw that it was using the main AirPort's 5GHz radio. I edited the file so it used the 2.4GHz band and imported it, but that didn't fix it.

I used Snow Leopard's AirPort Utility to check both AirPorts. The Main one has "Allow this network to be extended" checked. The Extender's "Connect Using" is set to "Wireless Network".

FWIW: Before I had the ac AirPort model, I had "n"-model AirPorts. Setting one up to be a wireless extender just worked.
 


I have two AirPort Extreme 802.11ac base stations, but I can't wirelessly extend the main AirPort's network. ... FWIW: Before I had the ac AirPort model, I had "n"-model AirPorts. Setting one up to be a wireless extender just worked.
Are you following AirPort documents?

See links at the bottom of the page for Roaming (requires base stations wired) and Extended (wireless). I don't recommend IPv6 be on. And I also don't recommend mixing old and new AirPort products. But double-check the config as one base is the primary (extended wireless base stations should be in bridged mode).
 


Thanks, Ed. The document's procedure worked fine when I set up my now-retired two 802.11n AirPorts a few years ago. The doc is outdated and applies to 802.11n AirPorts and older versions of AirPort Utility. For the primary AirPort it says "Select the “Allow this network to be extended” checkbox." This option was removed in newer versions of AirPort Utility, which is why I used Snow Leopard's version to verify this setting.

I watched a couple of YouTube videos showing how to do this (basically what's in the doc); it worked for them but doesn't for me.

I wonder if the latest 7.9.1 firmware on the 802.11ac models broke this.

The fact that neither another 802.11ac nor an 802.11n could be used as an extender points to the primary AirPort. But what's the problem?
 


... But what's the problem?
I found what caused the problem! I got the extender AirPort set up and running by resetting it to factory defaults and then doing a Manual Configuration using Snow Leopard's AirPort Utility 5.6.1. It just worked. I didn't change anything on the primary AirPort.

That means the extender AirPort was not being configured properly by any of Apple's current software (Mojave's AirPort Utility 6.3.9, iOS 13.2.2's Settings > Wi-Fi, and iOS 13.2.2's AirPort Utility).

After I got it set up, I changed some settings in Mojave, and it continued to work.
 


Depending on your use, "extending" an AirPort-based network might not be your best solution. WiFi extension always imposes a substantial performance hit on the throughput delivered to devices connected to the secondary WiFi access point, as part of the WiFi bandwidth is used to connect the two access points.

Modern mesh WiFi systems avoid this problem by using a separate, dedicated frequency for a "backhaul" channel to connect the access points. This minimizes the downstream throughput hit.

It might be worth your while to ditch the AirPorts and upgrade to a newer system.
 


Depending on your use, "extending" an AirPort-based network might not be your best solution. ...
Good points, but I don't actually need an extender since I live in a small apartment. I just couldn't accept that I couldn't get it to work. I'll leave it running for a couple of days to verify it's working OK and then keep it as a spare for my primary AirPort.
 


Good points, but I don't actually need an extender since I live in a small apartment. I just couldn't accept that I couldn't get it to work. I'll leave it running for a couple of days to verify it's working OK and then keep it as a spare for my primary AirPort.
I agree completely. Accepting this network challenge and succeeding builds confidence to address future issues that may or may not be outside your comfort zone.
 


Good points, but I don't actually need an extender since I live in a small apartment. I just couldn't accept that I couldn't get it to work. I'll leave it running for a couple of days to verify it's working OK and then keep it as a spare for my primary AirPort.
Sorry, Sam. I thought you were mixing old with new (which kind of explains why you needed Snow Leopard to configure that one). I will admit, once I moved to Orbi (small home), I kept the Time Machine AirPort Time Capsule and a few AirPort Expresses on separate WiFi for sending iTunes and home backup (until I get a NAS for Time Machine). I put a 4TB drive in the Time Capsule. I want a RAID-1 NAS for my local backups, and Apple's deficiency is here, wanting us to depend on them for cloud. Glad you got it resolved!
 


FWIW, here's my experience:

Had a 'refurb' Apple AirPort tower. Bought two of them via Amazon, one for home, one for other home in France (unfortunately the second one was opened in France where it was found to be DOA). The one here worked fine, but performance wasn't all it could be.

Read about mesh systems; the house in France is old and multi-story, and WiFi doesn't penetrate well. Bought a LinkSys Velop over here and set it up. Worked well. Seemed to provide noticeably quicker performance around the house, although really didn't seem to need the three stations I'd bought. (Took 'em to France and they worked well there.)

Decided that I'd like the nippier performance here, too (not to mention an actual supported product), so I bought a couple more of the things to install here. Yayy! Same nippy performance.

But there's one big difference. The AirPort's wifi network was, as best I could tell, the same network as the wired network in the house. Hook up your music server to the wired network, and your wifi'd iPhone saw it.

Not so with the Velop. Your iPhone cannot see the wired devices. To fix this, any device you want to be seen via wifi has to be wired to a Velop (via an ethernet switch if needed).

Damned nuisance, but all fixed now.
 


Sorry, Sam. I thought you were mixing old with new (which kind of explains why you needed Snow Leopard to configure that one). ...
Ed: I did mix old and new at my client's. I couldn't get it to work there, it had the exact same symptoms I had at home extending an "ac" AirPort with another "ac". I don't think the client needs the extender, but now I should be able to get it to work if necessary.
 


FWIW, here's my experience...
... Not so with the Velop. Your iPhone cannot see the wired devices. To fix this, any device you want to be seen via wifi has to be wired to a Velop (via an ethernet switch if needed)..
Can't you put the Velop into bridge mode? I did that with my Mercku mesh system, and everything is on the same network (although I wouldn't use it for IoT, but that's another story).
 


Can't you put the Velop into bridge mode? I did that with my Mercku mesh system, and everything is on the same network (although I wouldn't use it for IoT, but that's another story).
It’s a fair question, but as best I could tell, the Velop setup is one-track - you get their idea of a mesh system.

That said, I have (here at home) Ethernet holes in the wall, so a simple cable switcheroo tidies things up (plug wall into Velop, then Velop into local switch).
 





Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts