The laptop had an excellent-looking connection to the Beryl. That was the distracting part: I was looking at the connection nearest the test, not the connection feeding it.
On the same laptop, in the same position, direct upstream WiFi measured 303.74 Mb/s down and 365.94 Mb/s up. Through the repeater, it measured 10.39 Mb/s down and 13.12 Mb/s up. The laptop's LAN association reported -25 dBm and a negotiated rate of 1201 Mbit/s. That was a reason to inspect the uplink next, not proof that every possible LAN problem had been eliminated.
A speedtest through the repeater includes both wireless hops. The laptop's association only described its own hop.
Find the connection feeding the repeater
The upstream client details weren't surfaced in the UI views I inspected. The interface name gave me something useful to query: iwinfo apcli0 info.
That showed the uplink on 2.4 GHz at -74 dBm, with a negotiated rate of 286 Mbit/s. The negotiated rate wasn't the throughput I was getting through the whole connection. Remember that distinction before treating a large bitrate as reassurance.
Band Selection was set to Auto. I changed it to 5GHz.
For next time, the settings path was INTERNET, then the gear on the upstream connection card, then Repeater Options. The dashboard's Repeater shortcut took me to Multi-WAN instead. Same subject, wrong destination.
Don't diagnose from the timeout alone
The connection UI timed out after the change. I read that as failure, tried to abort, tried SSH, and eventually power-cycled the device when those attempts were unresponsive.
After reboot, the laptop joined the upstream WiFi directly rather than the repeater's network. A failed ping to the repeater gateway then looked like another router problem. Checking the laptop's actual network explained why that ping was misleading.
My notes attributed the connection delay to DFS. The useful reminder isn't a guaranteed waiting interval; it's that the timeout alone wasn't enough to tell me what had happened.
There was another misleading check waiting afterward. Querying apcli0 again returned an unknown association and an implausible signal value. ip link show showed that interface down and apclix0 up with LOWER_UP. Querying iwinfo apclix0 info found the active link. Its signal reading was -44 dBm.
Don't keep interrogating the old interface just because it answered before the change.
Keep both upload results
The post-change tests were better, but they didn't agree on upload:
| Test | Download | Upload |
|---|---|---|
| Before the change | 10.39 Mb/s | 13.12 Mb/s |
| First post-change test | 154.01 Mb/s | 37.73 Mb/s |
| Second post-change test | 163.43 Mb/s | 200.65 Mb/s |
Repeating the test was useful. Declaring the second upload result typical would be getting ahead of the measurements. More upload samples, watching for disconnects and confirming that the forced band survives a reboot remained follow-up work.
The note to keep is simple: inspect the upstream hop, check where the laptop actually connected, and find the live interface after changing bands. Those checks kept the verification from becoming another round of troubleshooting the wrong thing.