Every homelab eventually reaches the point where you run out of servers to break and start eyeing the router. Mine’s a FRITZ!Box 7690, sitting there quietly doing WiFi and internet things, never really audited, never really questioned. One evening I figured: why not hand Claude the login and see what it finds? One rule, non-negotiable: look, don’t touch. No changes, just an honest inspection.
What came back was more interesting than I expected – and backed by actual router logs, not vibes. 🧾
🔑 Getting In, Politely
First fun detail: the FRITZ!Box never actually asks for the password over the wire – not even once. Instead of “tell me your password so I can check it,” it plays a little verification game: the box sends over a random puzzle piece first. The password gets mixed together with that puzzle piece, run through a deliberately slow scrambling process tens of thousands of times over, and only the scrambled result gets sent back – never the password itself. The box does the exact same scrambling on its end with the password it has on file, and if both scrambled results match, you’re in.
The password itself never travels across the network at any point, in any form. Even someone sitting on the same WiFi capturing every packet would only ever see the puzzle piece and the scrambled answer – neither of which can be worked backward into the actual password. No browser needed to do any of this either – just a bit of scripting doing the same math a browser would. Nerdy, but reassuring: the login itself is solid.
Once in, the box’s own web UI backend (data.lua) turned out to be a goldmine – the exact same JSON the admin interface itself uses, just queryable directly. No clicking through menus required. 😌
📶 The Three Things Worth Fixing
Here’s the thing about WiFi settings: they sound abstract until you translate them into something everyday. So here’s the “explain it to my non-IT friend” version of what Claude flagged – and why.
1. The 3-Lane Street (2.4 GHz channel width)
Picture the 2.4 GHz band as a narrow street with exactly 3 non-overlapping lanes (channels 1, 6, 11 – everything else overlaps one of these). Normally your WiFi uses one lane. My box was configured to grab two lanes at once (“40 MHz”) for extra speed – except with only 3 lanes total on the whole street, that’s most of the road, and any neighbor’s WiFi is almost guaranteed to be parked in one of those lanes too.
The kicker: there’s a built-in “be polite” feature (20/40 MHz coexistence) that automatically backs off to one lane when it senses a neighbor – and it was switched off. So the box was taking two lanes, colliding with the neighbors anyway, and getting none of the promised speed benefit back because collisions force retransmits and slower fallback rates. Worst of both worlds. 🚗💥🚗
2. The Wide Highway With a Surprise Roadblock (5 GHz, 160 MHz + DFS)
5 GHz has way more lanes, so neighbor congestion isn’t really the issue there. My box was running the widest possible highway – 160 MHz, 8 lanes bundled together, maximum theoretical speed. Two catches, though: part of that spectrum (channels 52–64) is shared with weather and aviation radar. If the box detects radar, it has to evacuate that channel immediately, no negotiation – like a road getting closed on the spot for an ambulance. And a channel that wide spreads the same transmit power thinner, which usually costs you some range and wall penetration compared to a narrower 80 MHz channel.
Not wrong, exactly – just a speed-vs-stability trade-off I didn’t know I’d made.
3. The Spare Key Under the Doormat (WPS)
WPS is the “press a button on the router, press a button on the device, done” pairing shortcut. Convenient – like leaving a spare key under the doormat for guests. The catch: a few years back, researchers found a flaw in how the WPS PIN gets checked that makes it crackable far faster than an 8-digit PIN should be. If you’re not actively using it to pair new devices, it’s a spare key sitting under the mat for no reason.
📊 Receipts, Not Vibes
Here’s where it stopped being theoretical. Claude pulled the FRITZ!Box’s own system log – 1,088 entries spanning three weeks – and it turns out I actually have a small mesh going (ground floor, 1st floor, 2nd floor access points, not just one box). The numbers:
- 314× radar detected on the 5 GHz DFS channels (120–124), across the two upstairs APs, in three weeks. That’s roughly 15 times a day.
- 308 forced channel switches as the direct, immediate consequence of those radar hits.
- 138× “very strong interference source detected” on 2.4 GHz channels 1 and 11 – the exact neighbor-collision problem from point 1, logged in black and white.
- 12× the box’s own automatic quality logic got so unhappy with 2.4 GHz conditions that it force-narrowed the channel width itself, mid-operation.
So this wasn’t “might theoretically cause issues somewhere.” It’s been happening multiple times a day, quietly, for weeks, without me ever noticing anything more than the occasional “huh, WiFi felt sluggish for a second there.” 🤷
🎓 The Moral (So Far)
None of this is about radiation, health, or “too much WiFi” – channel width has nothing to do with transmit power, it’s purely a spectrum-sharing and speed-vs-stability question. But it’s a good reminder that “it’s been working fine” and “it’s actually configured well” are two very different claims, and sometimes you only find out which one is true by pointing an AI at your own router logs and asking it to just look. 😅
🛠️ Update: Actually Flipping the Switches
Back for round two, this time with permission to touch things. Turns out point 1 had a plot twist hiding in it: the “neighbor interference” on channel 1 wasn’t a neighbor at all. A fresh scan of the WiFi environment showed zero genuinely foreign 2.4 GHz networks nearby – every “other network” flagged was carrying my own router vendor’s MAC prefix. Two of my own four mesh radios (main box plus repeaters on three floors) had quietly parked themselves on the exact same channel, colliding with themselves from different floors of the same house. The neighbors were innocent the whole time. 🤦
Fix for that one ended up simpler than the coexistence toggle I’d planned: manually pinned the 2.4 GHz channel to 6, which was sitting completely empty. Channel 1 no longer shows up as active at all in the box’s own channel table, channel 6 does. Not a perfectly clean 1/6/11 split across all four radios – the channel is still 40 MHz wide, so it still reaches a bit into neighboring spectrum – but a real improvement over two of my own APs literally sharing a channel.
WPS: switched off entirely. Small footnote for accuracy – what this box actually exposes is Push-Button WPS, not the PIN-based version that has the brute-force weakness described above. Push-button mode needs someone physically standing at the box during an active pairing window, so it was never remotely exploitable here. Turned off anyway, on the grounds of simply not needing it anymore.
🚧 The One That Got Away
Point 2 – narrowing that 160 MHz highway down to 80 – is where this stops being a tidy success story. We know exactly what we want to change. We just can’t find anywhere to actually change it.
Went looking for the setting, and this is where it gets genuinely odd: the field is very much still there. Reading the box’s own internal data straight from its API shows a clear ht160: active = true — the setting exists in the config model, present and accounted for. What doesn’t exist is any way to reach it. Not the web UI (not hidden behind an “advanced view” toggle, not tucked into a collapsed section – AVM has quietly removed granular channel-width control from the interface entirely in recent FRITZ!OS versions), and not the same API either: that JSON backend happily lets you read the field, but the write side – the exact parameters a save request would need to actually flip it – isn’t documented anywhere, and even Claude, poking at the same endpoints the web UI itself uses, couldn’t pin down a confirmed, safe way to call it. Guessing undocumented POST parameters against a live config-save endpoint felt like exactly the wrong place to improvise – get it wrong and you don’t just fail to change the channel width, you risk quietly resetting some unrelated setting you never meant to touch.
The only surviving way anyone’s found to touch it at all is a third-party tool that edits the box’s raw configuration export file directly and re-imports it – and the community reports of that going sideways (a corrupted config, straight from a support forum thread) are exactly the kind of risk not worth taking on a router the whole household depends on. A WiFi hiccup is fine. A box that stops answering entirely is not.
So, for the moment, this one’s simply unsolved – not because the fix itself is in question, but because there’s currently no route to it that doesn’t carry more risk than the setting is worth. Filed under “keep an eye on it”: if a future firmware update brings a GUI control back, or a safer documented API path turns up, this is the first thing getting revisited.
🍂 Looking Ahead: FRITZ!OS 8.5 This Fall
Which, conveniently, segues into the actual reason to keep watching this space: an upgrade to FRITZ!OS 8.5 is planned for autumn, and the headline feature is Pi-hole-style ad and tracker blocking built directly into the box. Right now that kind of DNS-level filtering means running a separate device on the network; having it live natively on the router already sitting at the center of everything would be a genuinely nice simplification. Firmware update season doubles as “maybe the channel-width setting quietly comes back too” season – more on both once 8.5 actually lands.
