Fritz!Box 5590 Fiber DHCP/NAT-tabel Crash .....

[chocka]

Onderwerp: Fritz!Box 5590 Fiber DHCP/NAT-tabel Crash Bij Aanhoudende Rclone Upload-belasting

Hardware & Omgeving:

Component	Specificatie
Router	AVM Fritz!Box 5590 Fiber (Gigabit Fiber)
Firmware	FRITZ!OS 8.25 (laatste)
NAS	Synology DS213+ (SMB-share)
Server	Raspberry Pi 4 (Docker container: rclone:v1.75.2)
Client	Rclone View v1.6.8
Cloud	Internxt (HTTPS backend)
Netwerk	1 Gbps symmetrisch (upload/download)

---

Probleembeschrijving

Tijdens aanhoudende bisync of copy-operaties van NAS → Cloud via Rclone draaiend in een Docker container op Raspberry Pi crasht de DHCP-server en NAT/conntrack-tabel van de Fritz!Box 5590, resulterend in:

• Alle verbonden apparaten verliezen tegelijkertijd internetconnectiviteit
• Geen "Connection refused" — clients behouden IP, maar geen gateway/DNS-resolutie
• Herstel vereist volledige router reboot (stroomreset of resetknop)
• Probleem treedt opnieuw op zelfs met conservatieve Rclone-instellingen (--transfers 1, --checkers 1, --bwlimit 1M)

Vergelijking: Synology HyperBackup draait 's nachts zonder enige router-instabiliteit.

---

Waargenomen Symptomen

Symptoom	Frequentie
Internetverlies tijdens Rclone sync	Elke run
Andere apparaten aanvankelijk niet beïnvloed	~5-30 minuten na start
DHCP-leases verlopen (10 dagen geconfigureerd)	Niet de directe oorzaak
Vereiste router reboot	100% herstel rate
Windows TCP/IP-stack corruptie	Soms secundair probleem (netsh winsock reset nodig)

---

Geteste Rclone-configuratie

Alle configuraties geprobeerd zonder succes:

# Conservatief (mislukt)
--transfers 1 --checkers 1 --tpslimit 1 --bwlimit 1M

# Gematigd (mislukt)
--transfers 2 --checkers 2 --tpslimit 3 --bwlimit 5M

# Aggressief (verwacht falen)
--transfers 4 --checkers 8 --bwlimit 10M

Extra flags geprobeerd:

• --fast-list
• --track-renames
• --modify-window 2s
• --stats 1m
• --low-level-retries 1
• --contimeout 5s

---

Root-oorzaak Hypothese

Het probleem blijkt NAT/conntrack-tabel overbelasting te zijn, geen bandbreedte verzadiging:

1. Rclone verbinding patroon: Zelfs single-threaded (--transfers 1) creëert vele kortstondige TCP-verbindingen per bestand (HTTP/SMB metadata, headers, chunking).
2. TIME_WAIT accumulatie: Elke verbinding laat staten achter in de NAT-tabel van de router voor seconden/minuten.
3. Tabel overloop: Na duizenden bestanden (~200 GB dataset) vult conntrack-tabel zich, DHCP-dienst stokt.
4. HyperBackup verschilt: Gebruikt geoptimaliseerde Synology API met minder HTTP-transacties per bestand → minder NAT-druk.

Bewijs:

• Router CPU-gebruik blijft laag tijdens sync
• Bandbreedte-gebruik blijft onder 10 MB/s (ver onder 1 Gbps capaciteit)
• Alleen aanhoudende uploads trigger crash, niet korte transfers

---

Wat Werkt Zonder Crashes

Methode	Resultaat
Synology HyperBackup (native NAS app)	✅ Stabiel, nachtelijk
Korte Rclone transfers (<50 GB)	✅ Tijdelijke stabiliteit
Router reboot midden in transfer	⚠️ Reset NAT-tabel, crash herhaalt zich

---

Vraag om Inzicht

Aan AVM/Fritz!Box Ontwikkelaars:

1. Is er een bekende beperking met de NAT/conntrack-tabel grootte van de 5590?
2. Kan DHCP/NAT-handhaving worden aangepast? (bijv. TIME_WAIT-reductie, conntrack-limieten)
3. Zijn er firmware fixes gepland voor agressieve HTTP-clients?

Aan Rclone Ontwikkelaars:

1. Kan --tpslimit effectiever zijn? Momenteel triggerd zelfs --tpslimit 1 crashes.
2. Moet Rclone connection pooling implementeren? Vermindert nieuwe TCP-handshake overhead.
3. Zijn er flags/opties voor "router-vriendelijke" modus? (Minder parallele verbindingen, langere keep-alives)

Aan Community-leden:

Hebben jullie soortgelijke problemen ervaren met:

• Fritz!Box routers + Rclone?
• Hoog-frequent kortstondige TCP-verbindingen die NAT-uitputting veroorzaken?
• Alternatieve workarounds (andere protocollen, lokale Rclone, etc.)?

---

Tijdelijke Workarounds Onderzocht

Workaround	Resultaat
--bwlimit reductie (1M → 10M)	❌ Geen effect
--transfers / --checkers (1 → 4)	❌ Geen effect
--tpslimit (1 → 3)	❌ Geen effect
Router factory reset	⚠️ Tijdelijke fix
Windows netwerk stack reset (netsh)	⚠️ Alleen secundair probleem

---

Voorgestelde Oplossingen

Oplossing	Haalbaarheid
Router firmware fix (conntrack optimalisatie)	⏳ Lange termijn
Rclone connection pooling (minder handshakes)	⏳ Midden-termijn
Gebruik native NAS backup tools	✅ Direct
Rclone op lokale PC (Pi + RC API vermijden)	⚠️ PC moet aan blijven
Upgrade naar enterprise router (grotere NAT-tabel)	💰 Kostenintensief

---

Conclusie

Dit lijkt een hardware/firmware beperking in de Fritz!Box 5590 bij het hanteren van high-volume kortstondige HTTP/SMB-verbindingen van generieke clients zoals Rclone. Native NAS apps (HyperBackup) werken prima dankzij geoptimaliseerde protocollen.

Impact: Gebruikers met Fritz!Box routers kunnen Rclone niet betrouwbaar gebruiken voor grote cloud backups, ondanks voldoende bandbreedte en conservatieve instellingen.

Verzoek: Graag onderzoeken of:

1. AVM NAT/conntrack handling kan verbeteren in FRITZ!OS
2. Rclone een "low-overhead" modus kan toevoegen voor router compatibiliteit
3. Anderen praktische workarounds hebben gevonden

@FRITZ!webcare

[ Voor 3% gewijzigd door chocka op 12-10-2026 20:06 ]

[Nielson]

Misschien @FRITZ!webcare even taggen, zijn regelmatig actief op het forum.

[Kabouterplop01]

vele kleine sessies, waarin je de bandbreedte limiteert geven heel vaak ellende op een router.
Op een switch daarentegen heb je geen problemen. Switches kunnen dat prima.
Vroeger is exact voor dit issue MPLS bedacht.

Wat je moet doen is via een batch alles wat je wilt backuppen in een groot bestand zippen en dat synchronsieren. Dat zorgt voor flinke bestands chunks en wordt de MTU benut.
Hoef je je bandbreedte ook niet te limiteren, of je maakt er 500M van. Is de sync ook sneller klaar.

[chocka]

Ik heb inmiddels antwoord van Fritz Support:


U vraagt ons het volgende:
 
Is er een bekende beperking met de NAT/conntrack-tabel grootte van de 5590?
Kan DHCP/NAT-handhaving worden aangepast? (bijv. TIME_WAIT-reductie, conntrack-limieten)
Zijn er firmware fixes gepland voor agressieve HTTP-clients?
 
Graag wil ik op deze vragen gaan antwoorden:
 
Het zijn zeer specifieke vragen die diep ingaan op de architectuur van FRITZ!OS (die gebaseerd is op een aangepaste Linux-kernel).
 

1. Beperking van de groote van de NAT/conntrack-tabel

Ja, er is een beperking, maar deze is niet bekend door een vast gedefinieerd "getal" in de documentatie, maar door de Resourcebeheer van FRITZ!OS.

• Het probleem: FRITZ!OS is een gesloten systeem. In tegenstelling tot een standaard Linux-router (zoals OpenWrt of pfSense) heb je geen toegang tot de kernel-parameters (via sysctl). De grootte van de nf_conntrack-tabel is vastgelegd in de firmware-image.
• Het effect: Als je zeer veel gelijktijdige verbindingen opbouwt (bijv. door massieve P2P/Torrent, agressieve web-scrapers of zeer veel IoT-apparaten die constant kleine pakketjes verzenden), kan de tabel volraken. Het resultaat is meestal dat de box geen nieuwe verbindingen meer toelaat of dat de TCP-verbindingen "sterven".
• Hardware-limiet: De 5590 heeft wel voldoende RAM, maar AVM reserveert een groot deel van de resources voor de CPU-belasting (door de versleuteling en de GUI-stabiliteit) en de prioritering van VoIP/WLAN.

2. Aanpassing van de DHCP/NAT-afhandeling (TIME_WAIT etc.)

Kort antwoord: Nee.

• Geen shell-toegang: Je kunt geen parameters zoals net.ipv4.tcp_fin_timeout of de conntrack-timeouts handmatig aanpassen.
• DHCP-lease-tijd: De DHCP-lease-tijd kan wel in de gebruikersinterface worden ingesteld (vaak wordt deze door de provider opgelegd), maar dit heeft geen directe invloed op de ontlasting van de NAT-tabellen.
• Waarom dat zo is: AVM hanteert een "consumer-first"-benadering. De firmware is geoptimaliseerd zodat een standaardgebruiker nooit in aanraking komt met de netwerkstructuur. Diepgaande aanpassingen aan de TCP-stack zijn voor de eindgebruiker geblokkeerd.

3. Firmware-fixes voor agressieve HTTP-clients

Er zijn geen openbare roadmaps van AVM die expliciet "fixes voor agressieve HTTP-clients" beloven. Er zijn echter twee aspecten om rekening mee te houden:

• Indirecte fixes: AVM brengt regelmatig updates uit die de stabiliteit van het systeem verbeteren. Als "agressieve clients" ervoor zorgen dat de httpd (de webserver van de box) of het kernel-proces voor het routeren vastloopt, wordt dit vaak onder "stabiliteitsverbeteringen" geschaard.
• Het probleem van "Stateful Inspection": De FRITZ!Box is een zeer "stateful" firewall. Agressieve clients die duizenden verbindingen in zeer korte tijd openen/sluiten, triggeren de beveiligingsmechanismen van de box. Het is onwaarschijnlijk dat AVM de firewall "soepeler" maakt, omdat dit het beveiligingsniveau voor de gemiddelde gebruiker zou verlagen.

Wat kun je doen als je tegen de grenzen aanloopt?

Als je merkt dat je 5590 lijdt onder de belasting van je clients (hoge latentie, verbindingsonderbrekingen):

1. Hardware-offloading vermijden / ontlasten: Als je zeer veel verbindingen hebt, is het vaak efficiënter om een dedicated router (bijv. een kleine mini-PC met OPNsense of een Ubiquiti EdgeRouter) voorvóór de FRITZ!Box te plaatsen. De 5590 fungeert dan alleen nog als een puur glasvezelmodem (in de "Bridge"-modus of voor zover de provider dat toelaat – wat bij glasvezel vaak lastig is, omdat men hier meestal de GPON-modus moet behouden) of als een pure access point.
2. Client-zijde tuning: Verminder het aantal gelijktijdige TCP-verbindingen per client (bijv. beperk bij Bittorrent het maximale aantal verbindingen per peer/totaal).
3. DNS-outsourcing: Gebruik een eigen DNS-server (Pi-hole, Unbound) in het LAN, zodat DNS-opvragingen niet via de DNS-forwarder van de FRITZ!Box lopen. Dit ontlast de CPU van de box lichtjes.