https://bugs.kde.org/show_bug.cgi?id=521648
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from [email protected] --- Thanks for the pointer, Ben — you were right that it's local to me, not the mirror. Following your suggestion, I tested with throttled bandwidth (curl --limit-rate) to separate time-based from data-based failure: At 200K/s: connection reset after 84 seconds, having only transferred 16.4M At 50K/s: connection reset after 184 seconds, having only transferred 8.98M Both failures occurred in a similar time window (80-190s) despite a 4x difference in transfer rate and very different amounts of data transferred. That pointed to a time-based connection timeout rather than a data-volume or filtering issue. Root cause: my router's (Fritz!Box) NAT connection tracking was dropping idle/long-lived TCP sessions, and the default Linux tcp_keepalive_time of 120s wasn't sending keepalive probes early enough to keep the NAT entry alive. Fix: lowering keepalive settings resolved it completely — bashsudo sysctl -w net.ipv4.tcp_keepalive_time=30 sudo sysctl -w net.ipv4.tcp_keepalive_intvl=10 sudo sysctl -w net.ipv4.tcp_keepalive_probes=6 With this, the full 3.8G test download completed without interruption (4:29, 14.1M/s avg). Applying the same fix now to the VM where the original KDE Linux update failures occurred. Sorry for the noise, and thanks again for taking the time to test from your end. -- You are receiving this mail because: You are watching all bug changes.
