:strip_exif()/i/2005109948.png?f=thumbmini)
/u/224752/crop5770db9f40049_cropped.png?f=community)
Onderwerp: Fritz!Box 5590 Fiber DHCP/NAT-tabel Crash Bij Aanhoudende Rclone Upload-belasting
Hardware & Omgeving:
# 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:
Hebben jullie soortgelijke problemen ervaren met:
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:
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)
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:- Rclone verbinding patroon: Zelfs single-threaded (--transfers 1) creëert vele kortstondige TCP-verbindingen per bestand (HTTP/SMB metadata, headers, chunking).
- TIME_WAIT accumulatie: Elke verbinding laat staten achter in de NAT-tabel van de router voor seconden/minuten.
- Tabel overloop: Na duizenden bestanden (~200 GB dataset) vult conntrack-tabel zich, DHCP-dienst stokt.
- HyperBackup verschilt: Gebruikt geoptimaliseerde Synology API met minder HTTP-transacties per bestand → minder NAT-druk.
- 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:- 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?
- Kan --tpslimit effectiever zijn? Momenteel triggerd zelfs --tpslimit 1 crashes.
- Moet Rclone connection pooling implementeren? Vermindert nieuwe TCP-handshake overhead.
- Zijn er flags/opties voor "router-vriendelijke" modus? (Minder parallele verbindingen, langere keep-alives)
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:
- AVM NAT/conntrack handling kan verbeteren in FRITZ!OS
- Rclone een "low-overhead" modus kan toevoegen voor router compatibiliteit
- Anderen praktische workarounds hebben gevonden
[ Voor 3% gewijzigd door chocka op 12-10-2026 20:06 ]