Debugging Home Wi-Fi with Claude Code and the 5 GHz Radar Rules

My internet felt slow, so I ran a speed test: 78 Mbps down, 26 Mbps up. My plan is fiber at 5 Gbps down and 900 Mbps up, so something between the fiber and my laptop was eating more than 98% of the line.

The usual fix is an evening of clicking through the router's admin panel and guessing which setting matters. I had a lunch break, not an evening, so I asked Claude Code to do it instead. It ran from the desktop app with access to my Chrome and my Mac's terminal, and I ate while it worked.

The router already knows everything

The router is an iliadbox, the box my ISP ships. I logged in to its admin page myself. That page is a JavaScript app on top of a local JSON API, and the agent noticed. It clicked around for about a minute, then stopped taking screenshots and started calling the API from inside the logged-in tab:

const get = async (path) => (await (await fetch(`/api/v16/${path}`)).json()).result

await get("connection/") // line type, state, bandwidth
await get("connection/ftth/") // fiber module, optical power
await get("wifi/bss/") // the Wi-Fi networks
await get("wifi/ap/0/stations/") // who is on 2.4 GHz, with signal and link rate

Its first attempt used an older API version and got empty lists back for the access points. It asked /api_version, saw 16.1, and retried. I would have lost twenty minutes on that. The same endpoint reports the box as a Freebox Server, so the iliadbox runs the same software as Free's Freebox routers in France. Plenty of other routers have no documented local API at all. On those, an agent can still read the web interface page by page, just more slowly.

The line itself was fine: FTTH, link up, optical power in the normal range, and almost no traffic during the test. Whatever was slow was inside my apartment.

Seven devices on 2.4 GHz

The router was broadcasting two network names, one per band, which surprised me. I had set a single name for both bands on purpose, after earlier trouble with 5 GHz going quiet because of radar (more on that below). With one name, devices stay online on 2.4 GHz while 5 GHz is unavailable and then move back. The price is that the router and the device decide which band you're on, and they don't always pick the faster one. Two names give you control over the band, but a device can only fall back to a network it has saved.

At some point the bands had been split into two names again. My laptop had joined the 2.4 GHz one, the only one it had a password for, so it never tried 5 GHz. A second Mac, an iPhone, the printer, and three small devices that only identified themselves as wlan0 and lwip0 were on it too. That made seven clients on a 20 MHz channel, with fourteen neighboring networks visible in the same band.

On 5 GHz there was a single Pixel phone, holding a link around 1.2 Gbps with a weaker signal than my laptop had on 2.4.

The terminal confirmed it from the laptop's side:

system_profiler SPAirPortDataType | grep -A10 "Current Network Information"
#   Channel: 6 (2GHz, 20MHz)
#   Transmit Rate: 195

networkQuality -s
#   Downlink capacity: 62.026 Mbps
#   Uplink capacity: 28.970 Mbps

networkQuality ships with macOS and measures against Apple's servers, which makes it a decent second opinion next to a browser speed test. The Transmit Rate is the link rate the Wi-Fi negotiated before overhead, so real throughput always lands below it.

I joined the 5 GHz network and the agent ran the test again.

Switching bands was the whole fix. The 2.4 GHz band was too crowded to carry more than a few dozen megabits.

Then I mentioned the airport

I live near a small airport, and I already knew radar could knock out my 5 GHz Wi-Fi. That was the reason for the single network name. I didn't know how my router's settings played into it, so I asked the agent to check the rest of the configuration with the airport in mind. It went straight to the 5 GHz channel list.

Part of the 5 GHz band is shared with radar, and radar has priority. Wi-Fi may use those channels only under DFS (Dynamic Frequency Selection), which is a legal requirement in both Europe and the US, so any router sold there follows it. Before transmitting on a DFS channel, the access point has to listen for radar, usually for a minute. If it hears radar later, it must leave the channel and stay off it for 30 minutes. In Europe, channels 36 to 48 are free of this, while channels 52 to 64 and 100 to 140 are not. The US also has channels 149 to 165 free of radar rules. Most routers mark DFS channels somewhere in their channel settings. Mine did it through the API:

80 MHz:   36  40  44  48  52* 56* 60* 64* 100* ... 128*
160 MHz:  36* 40* 44* 48* 52* 56* 60* 64* 100* ... 128*

Every 160 MHz option needs DFS, including the one that starts at channel 36. A 160 MHz channel is so wide that the block from 36 to 64 includes the radar channels 52 to 64. Picking 36 by hand still means a minute of listening before the network starts, and the router still has to leave if radar shows up. Only 80 MHz or narrower on channels 36 to 48 avoids the rules in Europe.

I knew radar was the problem, but I hadn't connected it to channel width. My router was set to 160 MHz with automatic channel selection, which is the fastest option and also the one most exposed to radar.

Ten minutes without 5 GHz

While checking settings I asked whether the router was up to date. The firmware was 4.12.4, newer than any version I could find mentioned online, and the box installs pending updates when it restarts. So we restarted it.

The 5 GHz network didn't come back. The laptop fell back to 2.4 GHz, and the status endpoint showed why:

{
  "state": "dfs",
  "primary_channel": 124,
  "channel_width": "160",
  "dfs_cac_remaining_time": 360
}

On boot the router picked channel 124, which sits in the 5600 to 5650 MHz range used by weather radar. There, the listening period before transmitting is ten minutes instead of one. Any restart that lands on those channels means ten minutes without the fast network.

From the outside, this is what radar trouble looks like. The 5 GHz network disappears for about a minute, or about ten on channels 120 to 128, and then comes back, often on a different channel. Meanwhile your devices drop to 2.4 GHz or lose Wi-Fi entirely. Some routers log radar events. Mine doesn't show one that I could find, so the countdown in the status endpoint was my only evidence.

I watched the countdown drop to zero. The laptop rejoined 5 GHz on channel 124 at 160 MHz and posted the best result of the day: 1.16 Gbps down, 634 Mbps up.

That is about as far as Wi-Fi goes on this laptop. Its link rate at 160 MHz was 1729 Mbps, and real throughput landed around 1.1 Gbps. Getting closer to the 5 Gbps on the contract needs a cable, a 2.5 or 10 Gbps Ethernet adapter, and a router port that supports that speed. I haven't checked what my router's ports support yet.

160 MHz or 80 MHz

The agent laid out the trade-off:

• 160 MHz gets around 1.1 Gbps on this laptop, but the 5 GHz network can disappear for one to ten minutes after a restart, or whenever the router decides it heard radar.
• 80 MHz on channels 36 to 48 gets roughly half the top speed, with no radar rules at all.

The 6 GHz band used by Wi-Fi 6E and Wi-Fi 7 would avoid the question, since it has no DFS radar rules. It needs a router and devices that support it, and mine only has 2.4 GHz and 5 GHz radios.

I kept 160 MHz for now. Without a radar log, I don't know how often the airport actually kicks the router off a channel. If 5 GHz starts dropping out for a minute at a time, I'll move to channel 36 at 80 MHz and stop thinking about it. Half of 1.1 Gbps is still close to nine times what I started with.

Two security settings on the way

The audit turned up two problems unrelated to speed. The IPv6 firewall was off, so any device with a public IPv6 address relied entirely on its own firewall. WPS was also enabled on both networks. With WPS off, devices that join through the WPS button instead of a password, such as some printers and Wi-Fi extenders, now need the network password.

The agent only changed settings after I said yes. It fixed both through the same API with two PUT requests. Turning off WPS dropped the Wi-Fi for a few seconds and cut the agent's own connection mid-request. It checked from the terminal that the router was reachable again, re-read the settings, and confirmed both changes had stuck.

What the agent was actually good at

The router had all of this information the whole time: band, channel, client list, signal strength, DFS state, firewall flags. The admin UI spreads it across a dozen panels, and none of them tell you that seven devices on 2.4 GHz is your problem.

An agent with a logged-in browser tab can read the router's raw state in a minute, and with a terminal it can see the client side too. Seeing both at once made the 2.4 GHz problem obvious.

I knew about the radar from past outages, and a single network name was my workaround. I didn't know channel 124 had a ten-minute timer or that 160 MHz always means DFS, and I hadn't noticed the workaround was gone. If you live near an airport or a weather radar and your 5 GHz Wi-Fi vanishes for a few minutes after a power outage, that is probably why.