Every packet leaving the apartment used to go through a WiFi-repeater hop: the Beryl pulled the residential WiFi in on one radio and retransmitted it out the other. That hop was the bottleneck, not the ISP — a direct WiFi test from a different device on the same network ran well over the Beryl's repeater-WAN numbers, and if the ISP itself were the limit, that direct test would have been capped too. It wasn't. So the fix was a cable: get the Beryl off WiFi-as-WAN and onto the wall jack directly.
The plan had the wrong port
The written plan assumed a specific port — the one that had just freed up — could become the new WAN. It couldn't. The Beryl's firmware only exposes the WAN/LAN toggle on one specific labeled port; the other port's tab doesn't have that option at all, full stop. I only found this out because I opened the admin panel and looked before clicking anything, and it's a good thing I did: that WAN-labeled port was the one currently carrying the switch uplink.
That meant the fix wasn't "flip a toggle," it was a cable swap done in a specific order:
- Move the switch uplink off the WAN-labeled port onto the other port first.
- Flip the now-free port from LAN to WAN in Port Management, apply it.
- Only then connect the new wall-jack cable to that port.
Doing step 2 before step 1 would have put the switch on the internet side of the router — not just cutting off outbound traffic, but cutting the internal network off from itself, VLANs and all, while it was half-reconfigured. The order was the entire risk. I also had to manage this from the admin WiFi connection rather than the wired laptop, since the wired path ran straight through the exact switch connection I was about to move.
End state: the standard, fully supported layout, with the higher-rated physical port now carrying WAN instead of a LAN device.
What actually changed, measured
Before, from the same test machine over the same WiFi, same path, same everything except the WAN link itself:
- Download: 52.36 → 332.57 Mbps
- Upload: 94.37 → 318.15 Mbps
- Ping: roughly flat, ~14 ms → ~13 ms
That's about 6.4x on download and 3.4x on upload, with one variable changed. It even beat the direct-to-ISP WiFi reference test by around 130 Mbps on download — though that reference was a different device on its own WiFi link, so it removed two bottlenecks at once rather than isolating the WAN link cleanly. Worth remembering next time I'm tempted to read too much into a cross-device comparison: it tells you the order of magnitude, not a clean number.
Multi-WAN didn't need touching — but I checked anyway
Failover priority was already set to wired first, WiFi repeater second, with two more unused tiers below that. The Apply button was greyed out — nothing pending, because it was the firmware default the whole time. Nothing to click here. A MAC-cloning option also showed up once the port became WAN; left it at default. It's in reserve only because a past investigation found a different piece of network gear on this setup that would only ever accept the first device it saw — if the Beryl had failed to get an address on the new link, cloning the laptop's MAC would have been the first thing to try. Wasn't needed this time.
A priority list only says which link is preferred. It doesn't prove failover actually works. That needed an actual test.
Pulling the cable to find out
Ran a continuous ping to a public address from the wired laptop and pulled the WAN cable out of the Beryl mid-test. Result: 57 sent, 57 received, 0% loss, with two automatic switchovers — out to the WiFi repeater, then back once the cable went back in. Better than I expected: pulling a cable kills the link instantly, so the router doesn't have to wait on a health-check timer to notice. It just sees the link die and moves.
This was one test, one failure mode (a cleanly pulled cable), on one session. It's not a claim that failover is seamless under every kind of failure — it's a claim that it worked under this one, and that's the only kind of claim a test actually earns you.
The more interesting part was the shape of the latency, not just the headline number. On the wired path, every ping landed in a tight 0.2 ms band. On the WiFi backup, the range opened up to about 7 ms. Same rough average either way — the spread is what's different, and that spread is jitter. It's jitter, not raw average latency, that makes a call stutter or a game lag. TTL stayed constant through the whole test, which makes sense once you remember TTL counts routers crossed, not cables or radio — same router hops either way, just a different medium underneath. Worth remembering: TTL wasn't informative here because nothing about the route changed, only the transport did. That's a fact about this one test, not a general rule that failover is invisible at the network layer.
A second cable, a slower failover
Different test: instead of pulling the Beryl's link to the internet, I pulled the laptop's own cable to the switch — a different link entirely. The laptop did fail over to its own WiFi, but it took roughly six seconds, not the near-instant switch the Beryl made. The laptop had both a wired and a WiFi route to the Beryl already up, but the wired route had a lower (preferred) metric, so the OS kept trying the dead wired path until it finally gave up on it and fell back to WiFi. That six-second number is about this one machine's specific route priorities, not a property of failover or of the OS in general — a different metric setup would've failed over on a different schedule entirely.
The error output along the way was from the laptop itself, reporting to itself that it couldn't reach the gateway over a dead link — not a response from anywhere else on the network. Worth remembering the next time a local unreachable message shows up: it's the machine giving up locally, not evidence of anything happening further out.
Plugging the cable back in, the laptop's routing returned to the wired path on its own, no intervention needed. The one-line way to check which path a machine is actually using, rather than waiting on a notification, is a simple route-lookup command — good enough to just run instead of guessing.
Lessons for next time
A plan written from general knowledge of a device is a guess until the actual admin screen confirms it — check the real UI before acting, not after.
Order of operations can be the entire risk on a change like this. Every individual step was simple; the wrong order would have taken down the whole internal network, not just the internet.
A setting is a claim. A pulled cable is proof. Failover was configured the whole time and nobody knew if it actually worked until the cable came out.
Redundancy protects one link, not the whole chain. The Beryl's WAN has a backup now, and the laptop's own link has a slower one, but the single cable between the switch and the Beryl still doesn't have either. Fine for a homelab — the point isn't to eliminate every single point of failure, it's to know exactly where they still are.
The same WiFi backup path is the same mechanism whether it helps or hurts — it was a hidden failure in an earlier test, and a clean backup tonight. Worth remembering that it's not a "good" or "bad" path by nature, just a path, and what it does depends on what's actually being tested at the time.
Still open
Two things left hanging at the end of this session: a fresh configuration backup still needs to be taken, since the one on file predates this change and would undo it if ever restored. And the WAN port's negotiated link speed against the far end of the wall jack is worth checking at some point, just to confirm the rated 2.5 Gbps port is actually getting a matching link on the other side.