Three built-in wall Ethernet jacks stopped passing any signal at the same time. Wi-Fi on the same network kept working, which ruled out the obvious "the whole network is down" explanation immediately. Before blaming the wiring, I had to rule out the thing that's always the first suspect: the laptop and cable doing the testing.
Hold the laptop constant, change the far end
The check I used is the simplest one there is: whether the interface sees an electrical link pulse from the far end at all, before DHCP, before an IP address, before anything software can go wrong. All three wall jacks came back with nothing — not even a link light — using the same NIC and cable each time.
That result alone doesn't tell you where the fault is. So I took the same laptop and cable and tried them against two things I already knew worked: my own switch, and a second port on the building's ceiling-mounted access point that I hadn't used before. Both gave a clean link immediately. Same hardware, two different outcomes depending on what was on the other end of the cable — which is the whole point of a hardware isolation test: hold the variable you're not testing constant, and only change the one you are. That pattern cleared the laptop, the cable, the NIC driver, and DNS/DHCP/NetworkManager config all at once, and pushed the fault to something the three jacks share that isn't shared by the switch or the access point's spare port.
What the spare port turned up
Plugging into that previously-unused access point port gave a negotiated link — 100 Mbps, full duplex. The 100 Mbps ceiling is this laptop's own NIC limit, not necessarily anything about the port itself; worth remembering before reading more into that number than it supports.
With Wi-Fi switched off to make sure nothing was quietly riding the wireless path, the full chain checked out clean: the interface got an address, reached the gateway, reached a public address directly by IP, and reached a public hostname by name. Nothing dropped. The address range handed out is carrier-grade NAT space, which is normal for how a shared building network provisions a whole building rather than a sign that anything was misconfigured.
The wall jacks themselves were still dead at the end of this — I didn't find or fix whatever's wrong with that run, just confirmed the fault isn't the laptop, the cable, or the building's wired service in general.
One client, or more than one?
The open question coming out of the first session was whether that spare access-point port would serve more than one device, or only the one it saw first. I didn't get a real answer until later, after running a cable to reach the port properly: swapping a second, different device onto the same port got it a working DHCP lease without trouble, but it could not reach the gateway at all — not on the first try, and not after reseating both ends of the cable.
My read on that is a sticky-MAC or port-security lock on the building's managed switch — DHCP handled separately from everything else, so the lease succeeds while the actual gateway path stays closed to a second device. But that's an inference from one failure signature, not something I independently proved by eliminating every other explanation. Worth writing down as "this is what I think happened and why," not "this is settled."
Detours that weren't the real problem
None of these were the bug I was chasing, but each one cost time before I recognized it for what it was:
- Killing a DHCP renew mid-request (Ctrl-C before it got a fresh answer) didn't fail cleanly — it left a stale cached lease behind that looked like a new problem. Let DHCP commands finish or time out on their own.
- A bridge interface kept its old default route after the physical cable moved to the new port. The new interface only had a route to its own local subnet. Pinning a client to a specific interface pins the socket, not the routing table — without an explicit route added for that interface, anything without a matching connected route still fails even though the interface itself is fine.
- One classic command-line speedtest tool returned a reading with nothing to do with the actual link — a nonsensical result that was the tool being broken, not the network. A direct download test against a known file host was the more trustworthy fallback.
- A package manager hung silently instead of erroring when the only route to the internet was down. It looked like a package-manager problem; it was the routing problem above, one layer underneath.
The wall jacks are still a mystery as of this write-up. But the method here — hold the laptop and cable fixed, swap only the far end, and don't trust a single tool's word for "broken" without a second way to check — is the part worth keeping around for the next time something upstream of the laptop goes quiet.