MacInTouch Amazon link...

AirPort issues/alternatives

Channels
Apple, Security, Products
... I tried, over the years, LinkSys, NetGear, AirLink+, D-Link, TP-link, Bountiful, Cisco and Belkin.
Having seen a few of this kind of experience here, I wonder if some manufacturers' businesses depend on people failing to use their hardware and then trashing the hardware or recycling it (to other users), if the "I give up" date is beyond the reseller's return period. (I know I've gotten to that point with three different WiFi extenders and one Ring accessory.)
 


Our smallish, ranch-style townhouse (1300 sq. ft.) has had dead zones in it from the onset of our use of WiFi, but it took the purchase of an Apple TV that paused the streaming program every few minutes to finally prompt action.

We ended up getting a 3-pack of xFi cubes (Xfinity is our ISP), and they greatly improved our house-wide WiFi. But here's a piece of information that wasn't offered at either the Xfinity store or, later, at Best Buy:

While you have a choice to rent a gateway (or modem) from Xfinity, they also support a small handful of purchase options. These are available at Best Buy and Xfinity stores and are branded 'Xfinity' right on the box. I bought a nicely spec'd Motorola and made the switch. That's when I discovered (after an afternoon's absolute torture on the phone with Xfinity) that xFi pods do not work unless the gateway is rented. By the time I got around to buying the Motorola, the return window on xFi Pods had closed. So, the Motorola went back.

I'm not unhappy with the pods, just that I'm locked into renting my device if I want to use them. (I wonder if it may be possible to rent the modem, buy my own router, and still be able to use the pods, though my space is limited and I don't need another device on my desk.)

You can read an xFi Pod review elsewhere on MacInTouch: Post 2189.
 


One reason I haven't looked more closely at the Ubiquiti AmpliFi HD for my clients is because they are wireless only. That's fine for some (many) setups but certainly not all, and having wired backhaul is obviously desirable when possible.
The pre-bundled kits are wireless only (well, don't combine as easily). If you want to build your own mesh (at a higher price), you can. You can combine different elements of the AmpliFi line with each other but have to choose carefully. There is a compatibility guide
in the docs. So, for example, you can buy three standalone HD routers and combine them into a mesh. You set up the first to be the main router and then can set up the others on backhaul in what they call "Router as mesh point" (RAMP), admittedly a two-step process. The standalone AmpliFi Instant also can work in RAMP mode....

The pre-bundled ones are better at "buy once and done". If you need something more custom or evolutionary, then it works better to not buy the kits and just do the manual configurations.

AmpliFi has also made some progress in bridge meshes and guest mode. Systems on a LAN can see devices on a Guest network but not vice versa. So if you put the IoT devices on the guest network, you can reach them for control, but if they get compromised, the ioT devices don't get back in. There isn't all the flexibility of the UniFi devices, but there is a reasonable amount of relatively common use cases available there.

I can't find it explicitly in the user docs, but I suspect the RAMP mode routers can still wirelessly bridge to their LAN ports in RAMP mode. The 'upstream' port is the 'WAN' port, so I suspect they can still traffic data to the upstream/WAN port in RAMP mode just as they would if were the 'main' router. For example:
AmpliFi Community said:
The main router has a bridge mode, too.

The dedicated MeshPoint "coverage extenders' are wireless only. They have some upsides in being somewhat directional and have more convenient placement. But the standalone AmpliFi Instant is actually less expensive (and has one LAN port).
 


.... Regarding your statement above, I'm either reading it wrong or there is no difference to the Airport base station (ac model). My Airport base station "broadcasts separate SSIDs, and uses separate passwords, for the main access and guest access". It handles "both 2.4GHz and 5GHz", and I have both these networks with different SSIDs. Am I missing something?
"Out of the box", the Amplifi products implement 'band steering'. They'll present the 2.4GHz and 5GHz bands under one SSID and negotiate with the clients as to which one to join (or get off). So, the 'different' SSD is to add yet another SSID on top of that (and the Guest one).

The additional SSID would be very useful for older Wi-Fi devices, which are 2.4GHz only and "don't like" or are incompatible (if old enough) with band steering.... Technically, you can turn band steering off, also, if you're having problems with devices. Or if you simply prefer to keep 5GHz ones explicitly segregated. Having the additional SSID means one can have both approaches at the same time.

The Additional SSIDs don't deploy over the whole mesh, so they are useful for edge-case devices.
 


FWIW, I have a second home in Normandy, France. Some fine US products aren't certified for use there (Eero, for example) and so I had to look elsewhere.

It's a three-story house. There's no fibre or cable or... and so internet connection is via a 4g 'box' - cellular radio on one side, wifi and ethernet on the other. I've had an old, flat AirPort Express for years, and dragged it over. With it and the 4G box on the middle floor, there was some wifi connectivity throughout the house, but weak, so I bought a pair of refurbed tower AirpPort Expresses. Installed one at home, the other here. Of course, the second was DOA...

My use case may not be general, but it imposes some restrictions: in the living room lives the hifi system, which is a NAD preamp driving a power amp driving stereo speakers, with music being sourced from either a Mac Mini running Roon or an FM tuner. (Roon is like a high-end iTunes program, if you've not heard of it before.)

Roon works best (the preamp shows you on its front panel what is playing from Roon) if you use a network connection between the Roon box and the preamp. Using wifi for this caused many hiccups and stuttered music; the obvious thing was an Ethernet switch, which meant a wifi range extender or equivalent. But the extender I tried was no improvement.

So, in the end, I bought into the LinkSys Velop system online from Amazon.fr. There are four units scattered around the house (which is an 18th century building, unfriendly to the transmission of wifi through walls), one wired to the 4G box, and the one in the living room wired to an ethernet switch which is connected to the NAD and Mac Mini/Roon.

The Velop units seem to work, but three criticisms (all livable-with):
  • Their "all is working well" indicator is a steady light-blue glow from the top-mounted LED. This is disturbingly close in color to the "I've just reset/been turned on and am booting up" blue.
  • They take a looooong time to go from being turned on to being happily meshed (minutes).
  • They de-mesh themselves from time to time for no apparent reason.
 


Finally replaced an AirPort wireless network with Plume devices and am very happy with the results so far. Upgraded to a gigabit broadband connection, added a relatively inexpensive TP Link 8-port gigabit switched hub to interconnect Plume pods (you can daisy-chain dual-port Ethernet Plume pods via a backbone hub this way) and, across eight Plume SuperPods, now have upwards of 50 devices running smoothly. This includes live streaming TV access and a lifetime support subscription at $200 flat fee.
 


This is helpful info. I am under the task of recommending a new wifi setup for an old (time, not age) client I had. I originally installed Airport TC with AE throughout the home. However, they are building a new home, and I asked them make sure the electrician is Low-Voltage certified and pulls some Cat6 runs to ceiling space (attic) and rooms while the walls aren't even up yet. But I was going to suggest access pointes from Ubiquiti (Unifi AP HD, Unifi Gateway, 16-150W PoE switch, AP Outdoor for coverage near poolside). House not exactly wifi-friendly (metal roof, cement-lapboard siding, thermal-coated window panes).
Without a heatmap, I can't predict if one access point per floor will suffice or be overkill.
 


No, the AmpliFi MeshPoints are wireless only.
Note that the router unit of an AmplifiHD system can also serve as a mesh point, and the system is capable of working via an Ethernet cable connecting routers and using the ones in bridge mode as mesh points. My railroad-style apartment uses this setup with the ISP connection and one AmplifiHD router at one end and one in my office at the other end serving as a mesh point (and clock on my desk). It was only slightly more expensive to purchase the routers separately then purchasing a router+one mesh point system.
 



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.
 


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

Latest posts