This content originally appeared on DEV Community and was authored by Lucas Czekaj
A deep-dive into troubleshooting an "impossible" network outage that wasn't my Mac's fault at all.
The Perfect Setup, The Impossible Problem
I believe in building a robust home lab. When you’re a startup founder, stability isn't a luxury; it's a requirement. So when I upgraded my network to a prosumer-grade UniFi Cloud Gateway Ultra and a U7 Pro AP, I expected rock-solid performance for my workhorse: a beastly 64GB, M4 Pro Mac Mini.
Instead, I got a nightmare.
Once or twice a day, my Mac would be completely cut off from the network. The outage would last for about a minute, then spontaneously resolve. Pings to my gateway (192.168.0.1) would time out. SSH sessions would drop. But the Wi-Fi icon was always off, as usual, and macOS reported the wired connection was active. For a founder who lives on video calls, this was unacceptable.
Thus began a week-long odyssey to hunt down a ghost in my machine.
Act I: The Usual Suspects (and a Lot of Red Herrings)
Every good troubleshooter starts with a list of suspects. Gemini 2.5 Pro, Claude 4 Opus, and I went through them all, and each one led to a dead end.
1. The "It's a Software Bug" Theory:
My first thought was a software issue on the Mac. I was running OrbStack for my Supabase development environment and Tailscale for VPN. These tools hook deep into the network stack. Could they be the cause? We also saw a storm of mdworker (Spotlight) activity in the launchd logs, a classic source of system-wide slowdowns.
- Verdict: False. The issue persisted even after quitting both OrbStack and Tailscale. The
mdworkerissue was a red herring.
2. The "It's a Hardware Problem" Theory:
Maybe it was a bad cable, a faulty port on my new UniFi gateway, or a dying NIC in the Mac Mini?
- Verdict: False.
netstat -iconsistently showed zero input or output errors (Ierrs 0, Oerrs 0). The link was always active at 1Gbps with flow control. The hardware was solid.
3. The "It's a Network Protocol War" Theory (The Great BPDU Hunt):
This was our most promising lead for days. My Mac, by running OrbStack, was acting as a virtual switch. Virtual switches can sometimes send out BPDU (Bridge Protocol Data Unit) packets, which are the language of the Spanning Tree Protocol (STP) that physical switches use to prevent network loops.
Our theory was that my new UniFi gear was seeing these BPDUs, thinking a switch was misconfigured, and blocking the port as a safety measure. We went deep down this rabbit hole:
- We identified a small 4-port switch under my desk.
- We found it had a physical "Loop Prevention" toggle, which was off.
- We enabled it, turning the switch into a BPDU filter.
- Verdict: False. My credibility took a major hit here. A day later, the outage happened again. The BPDUs weren't the culprit.
Act II: The Impossible Clue
During one of the outages, I made a bizarre discovery. While I couldn't ping my local gateway, I could still load HackerNews. I clicked a link on the page to a random site, offchess.com, and it loaded too.
This should be impossible.
Both of those sites resolve to IPs behind Cloudflare. I also use Cloudflare for my own DNS fallback (1.1.1.1) and hosting. This meant my Mac was in a bizarre state: it was cut off from its own local network but had a live, working connection to a specific slice of the public internet.
This clue stumped my AI assistants completely. The logs showed no VPNs were active. It wasn't Tailscale Funnel. It wasn't a routing issue. It defied all standard models.
Act III: The Grand "Aha!" Moment
The real breakthrough came, as it often does, from finding a way to reliably reproduce the "intermittent" issue. I noticed that the network would drop every single time I plugged my iPhone into my Mac via USB, and again when I unplugged it.
This was the key. Claude finally had the trigger event it needed. Claude 4 Opus pointed out a critical detail in the logs I captured before and after an iPhone-triggered outage:
The MAC address for my gateway 192.168.0.1 was changing.
- Before (Working):
? (192.168.0.1) at [MAC_ADDRESS_OF_GATEWAY] - After (Outage):
? (192.168.0.1) at [DIFFERENT_MAC_ADDRESS]
This wasn't a software conflict on my Mac. This was ARP Poisoning.
The True Culprit: The Buggy Switch's Ghost
The real villain was a cheap, 8-port TP-Link managed switch that my Proxmox server and the under-desk switch were plugged into. Here’s the perfect crime it was committing:
- The Bug: The switch has a firmware bug. When its DHCP client fails to get (or keep because of an internal bug) an IP lease from my UniFi gateway, it's programmed to fall back to a hardcoded default IP.
- The Conflict: That hardcoded IP is
192.168.0.1—the exact same address as my gateway. - The Poison: The switch, now wrongly thinking it is the gateway, starts responding to ARP requests for
192.168.0.1. - The Heist: When my Mac flushed its ARP cache (triggered by the iPhone connection), it would broadcast "Who has
192.168.0.1?" If the buggy switch's reply was the last one my Mac heard, it would incorrectly map the gateway's IP to the switch's MAC address. - The Outage: All my internet-bound traffic was being sent to a switch port that didn't know how to route it, creating a black hole. My connection was dead. The outage ended whenever the ARP cache timed out and the Mac was lucky enough to get the real gateway's reply first.
The Fix: Taking Away the Keys
After TP-Link themselves acknowledged the bug and released a firmware update that did nothing to fix it, I took matters into my own hands. I logged into the switch's admin panel and essentially killed its networking:
- Disabled its DHCP client.
- Assigned it a random, unused static IP address.
- Set its default gateway to
0.0.0.0, ensuring it could never phone home or talk to the wider network.
I put the switch in a configuration box where it could do nothing but its primary job: forward packets.
The network has been stable ever since.
Lessons Learned
This journey was a brutal, humbling reminder of some core networking truths:
- Don't Trust, Verify: The network can, and will, lie to you. Just because a link is "active" with no errors doesn't mean it's working.
- The Dumbest Device Can Be the Smartest Criminal: The problem wasn't my high-end Mac or my pro-grade UniFi gear. It was the cheapest managed switch in the chain, with a single firmware bug.
- Find the Trigger: "Intermittent" problems are often just complex problems with a trigger you haven't found yet. The iPhone connection was the key that unlocked the entire mystery.
- Sometimes You're Not Crazy: If the symptoms seem to defy the laws of networking, it's possible a device on your network is breaking those laws. ARP poisoning, while rare in a home lab, is a real and devastating attack—even when it's unintentional.
So if your network is acting strange, start with the simple stuff. But never forget that sometimes, the problem is a ghost in the machine you'd least expect.
This content originally appeared on DEV Community and was authored by Lucas Czekaj
Lucas Czekaj | Sciencx (2025-07-11T00:27:30+00:00) When your home network lies to you. Retrieved from https://www.scien.cx/2025/07/11/when-your-home-network-lies-to-you/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.