FRITZ!Repeater Losing Connection: 4 Causes You Can Fix Yourself

Wi-Fi that “drops out” several times a day, while your actual internet connection is working fine. Sound familiar? This post walks through a real case: three FRITZ!Repeaters running behind an ISP-supplied router, with the network failing multiple times daily. The fix turned out to have nothing to do with faulty hardware — it was sitting in the event log the whole time.

The symptom: internet down, but not really

The complaint is almost always phrased the same way: “the internet keeps dropping”. But there’s one detail that changes everything:

If I switch over to the guest network, the internet usually comes straight back.

That’s not a minor detail. If switching SSID fixes it, your internet connection was never down. Your device stayed attached to an access point that no longer had a usable path behind it, and connecting to a different network forced it to start over. So you don’t have an ISP outage, and you probably don’t have a broken repeater either — you have a roaming and steering problem.

This also explains why replacement hardware so often helps “for a while” and then fails again: swapping units reconfigures and re-pairs everything. It doesn’t repair anything.

Always start with the event log

Log in to the repeater at fritz.repeater and go to System → Event Log. Here’s a real-world excerpt (anonymised):

12:14:40  [Living room] Repeater registration at the base station failed:
          connection setup failed. MAC address: XX:XX:XX:XX:XX:XX
12:14:35  The FRITZ!Repeater settings were changed via the user interface.
11:58:55  Internet connection IPv6: DHCPv6 error, cause 8
          (no prefix for this ia)
11:58:35  5 GHz band unavailable for 1 min. on the selected channel
          132-136 due to a check for priority users (e.g. radar).
11:58:35  Internet connection established.
11:58:30  Wi-Fi transmission quality improved by reduced channel
          bandwidth (2.4 GHz).

AVM’s own troubleshooting guide opens with an excellent diagnostic question: does the log contain events from before the moment things went wrong, or does the list only start afterwards? If it only starts afterwards, the repeater is rebooting itself — and that’s an entirely different problem (power supply, overheating, hardware) than Wi-Fi steering.

The DFS red herring

That line about “a check for priority users (e.g. radar)” looks alarming. On DFS channels (52 through 140), consumer equipment has to yield to weather and aviation radar, and when it does, 5 GHz goes away. It’s a classic cause of unexplained dropouts — but it isn’t automatically your cause.

Look at the timestamp. In the log above, the DFS message appears at exactly the same second as “Internet connection established”. That isn’t a radar detection — it’s the mandatory Channel Availability Check: before transmitting on a DFS channel, the radio has to listen quietly for one minute first. This happens every single time the radio starts, whether or not there’s a radar installation within a hundred miles.

The rule of thumb: a DFS message is only suspicious when it lines up with a moment things actually broke — not when it lines up with a reboot or a settings change.

The reverse is true too. The non-DFS channels 36 to 48 are absolutely packed in dense housing, while the higher DFS channels are often empty. Cleaner spectrum can easily outweigh the theoretical radar risk. Plenty of people who manually move to a DFS channel see things improve.

Cause 1: it isn’t actually a mesh

This is the big one. FRITZ!Repeaters don’t form a mesh simply because you’ve put several of them in the house. One device has to take the role of Mesh Master, distributing settings and handling client steering centrally.

If a third-party router sits at the head of the chain, it can’t fill that role. AVM’s answer is to configure one repeater as the Mesh Master; it then builds its own network behind the ISP router and passes settings down to the others. AVM explicitly recommends turning off the Wi-Fi on the ISP router when you do this.

Skip that step and you don’t have a mesh — you have a handful of independent access points that happen to broadcast the same network name and coordinate nothing about which client belongs where. That’s the perfect recipe for devices clinging to a weak or dead access point.

How to verify

• On the Mesh Master, go to Home Network → Mesh.
• Does every repeater show a mesh icon? If not, that unit isn’t participating in steering at all.
• On each repeater, check under Home Network → Mesh → Mesh Settings that the option to adopt settings from the Mesh Master is enabled.

Cause 2: band steering is switched off

Two settings determine whether your mesh can steer clients at all. Both live under Wi-Fi → Wi-Fi Network → Additional Settings:

1. Disable the option to use different names for the 2.4 and 5 GHz networks. If each band has its own SSID, band steering is impossible. Devices pick a band themselves and then stick to it — including when that band has become unusable.
2. Disable “hide the name of the Wi-Fi network”. A hidden SSID blocks mesh Wi-Fi steering and causes connection failures on some clients. The security benefit is essentially zero; the cost is real.

While you’re there: keep your network name to letters, numbers and spaces. Not every client handles accented or special characters gracefully.

Cause 3: IPv6 with nowhere to go

This log line deserves far more attention than it usually gets:

Internet connection IPv6: DHCPv6 error, cause 8 (no prefix for this ia)

Here’s what’s happening. The repeater runs its own network behind the ISP router, so you’re running double NAT. The ISP router isn’t delegating an IPv6 prefix, which means your FRITZ network advertises IPv6 while there’s no working path behind it.

The effect is subtle but genuinely annoying: clients try IPv6 first, hit a timeout, and only then fall back to IPv4. To the user that feels exactly like “the internet is down”, even though the connection is technically fine. And yes — this one also clears up temporarily when you reconnect.

Fix: disable IPv6 under Internet → Account Information → IPv6. In practice you give up nothing.

Cause 4: repeaters chained to repeaters

Three repeaters in the house doesn’t mean all three can see the base station. If repeater C is connected through repeater B rather than the Master, available bandwidth halves at each hop and the link gets noticeably more fragile.

• Log in to each repeater and check which device it’s connected to, and at what signal quality.
• Make sure every repeater has a direct line to the Mesh Master.
• Can’t manage that? Many FRITZ!Repeaters have a LAN port and can run as a wired access point. An Ethernet backhaul is by far the most stable setup available to you.

Smaller signals worth reading

Reduced channel bandwidth on 2.4 GHz

The message “transmission quality improved by reduced channel bandwidth” means the radio has fallen back to 20 MHz because of interference. That’s sensible behaviour in itself, but it’s telling you your 2.4 GHz spectrum is congested. Consider pinning that band to channel 1, 6 or 11.

Failed repeater registrations

A “registration at the base station failed” message immediately after a settings change is harmless — that’s expected. If the same message appears at random moments with no trigger, a repeater really is losing its base station, and you should be looking at placement and signal strength.

Guest network

A second SSID across the same radios doubles management traffic. Switch the guest network off for a few days purely to eliminate the variable. If you need it, run it on one access point rather than everywhere.

Firmware

Update every repeater to the same FRITZ!OS version via Home Network → Mesh → Check for updates. Version mismatches between mesh members produce connection issues that are miserable to trace. Don’t forget your clients’ Wi-Fi drivers and operating systems either.

Automatic or manual channel selection?

Advice diverges here, and reasonably so. AVM recommends leaving automatic channel selection on: the Master continuously analyses the environment and moves away from interference by itself.

There’s a good argument for that. But when you’re chasing a persistent problem, pinning the channel manually is a perfectly sound diagnostic step — you remove a variable and can see whether the pattern changes. My advice: pick one approach and stick with it for at least a week. If manual doesn’t help, switch automatic selection back on rather than working your way through a third and fourth channel.

Checklist

1. During an outage, test a wired device. If it keeps working, this is Wi-Fi, not internet.
2. Read the event log, paying particular attention to timestamps relative to the failure.
3. Confirm there’s one clear Mesh Master and that the ISP router’s Wi-Fi is off.
4. Enable band steering: one SSID across both bands, and don’t hide the network name.
5. Disable IPv6 if the log shows DHCPv6 errors.
6. Check that no repeater is chained behind another. Use Ethernet wherever you can.
7. Bring all firmware to the same version.
8. Look hard at placement: central, high up, clear of metal, radiators and large plants.

Closing thought

The biggest time saving here comes from resisting the urge to replace hardware. If a swap helps “for a while” and the problem then returns, the hardware was never broken — the reinstallation was what helped. The event log will tell you where to look within five minutes, and the answer is almost always a setting rather than a defect.

If the problem persists on one specific device afterwards, the fix probably lies with that device. If it persists across all devices in one part of the house, it’s coverage or placement. If it persists everywhere, there’s still a setting that isn’t right.