[Problem] Download blockiert gesamtes Internet/Surfen

[Novgorod]

Hiho,

ich habe eine fritzbox 7330 SL mit 1&1 an DSL 16000 und seit einiger zeit wird das internet komplett blockiert, wenn irgendwo ein download mit voller bandbreite läuft (windows updates oder sonst was) - es gibt praktisch 100% packet loss, solange der download läuft, unabhängig vom protokoll (http, skype, messenger, ping, geht alles nicht).. es war allerdings nicht immer so, sondern erst seit einigen wochen oder monaten (schwer einzuschätzen).. ich bin mir auch ziemlich sicher, dass es an der fritzbox liegt, weil ich alles andere weitestgehend ausschließen konnte:
- es passiert mit unterschiedlichen rechnern, per WLAN und per kabel
- während im browser ein download läuft und deshalb z.b. google nicht mehr antwortet, kann ich mit demselben browser immernoch aufs webinterface der fritzbox zugreifen (ist also wohl kein OS-problem und kein netzwerkproblem seitens der fritzbox, sondern betrifft nur das internet-routing)
- wenn ich den download für eine anwendung per software limitiere (z.b. auf 1,2MByte/s bei verfügbaren ~1,7MByte/s), geht alles - aber das ist ja nicht sinn der sache, einen router zu haben
- es ist egal, ob der download über den browser läuft oder per auto-updater (windows oder andere software) oder z.b. per jdownloader, es liegt also nicht an der software (ich habe allerdings keine downloads über einen anderen port als port 80 probieren können)
- das "QoS" der fritzbox ("Priorisierung") bringt hier garnichts, sollte auch eher nichts damit zu tun haben - z.b. kann ich http/surfen als hintergrundanwendung definieren, was aber garnichts ändert (ping und andere protokolle werden immernoch beim download blockiert).. es müssen ja nicht anwendungen gegeneinander balanciert werden, sondern verbindungen innerhalb einer anwendung

es scheint, dass möglicherweise eins der letzten updates das routen kaputt gemacht hat - die 7330 pfeift ja eh schon auf dem letzten loch (extrem unterdimensionierte hardware, startet gerne mal neu, wenn man versucht sich im webinterface einzuloggen), aber das problem tritt auch frisch nach dem neustart auf, wenn das webinterface noch halbwegs benutzbar ist.. ich habe diverse ähnliche probleme von anderen leuten gefunden (wobei überwiegend mit kabel und nicht DSL) und keiner hatte eine lösung außer den router zu wechseln.. mich wundert es bloß, dass "früher" alles ok war.. was kann ich sonst noch probieren? gibt es irgendeine "versteckte" config für das QoS von verbindungen?

 

[chilango79]

FirmwareNUMMER?
Was ist genau vor "seid einiger Zeit" geändert worden?

Ansonsten einfach mal die Einstellungen sichern und anschliessend resetten oder besser recovern.
Danach NICHT die Sicherung einspielen sondern nur die DSL-Verbindung konfigurieren und testen.
Besteht das Problem weiterhin? Wenn nicht, dann die Sicherung wegwerfen und alles von Hand neu konfigurieren

 

[thtomate12]

Reboots liegen vielleicht am unterdimensionierten Netzeil.

 

[Novgorod]

FirmwareNUMMER?

die neueste natürlich, 06.30.. geändert wurde eigentlich nichts.. factory-reset werde ich mal ausprobieren..

 

[MuP]

... mich wundert es bloß, dass "früher" alles ok war...

Früher waren die "Innereien" der 7330 und des Netzteils noch frisch und saftig, inzwischen wohl ausgetrocknet.
In den meisten Fällen betrifft dies die billig-billiger-am billigsten-Elektrolytkondensatoren.
Das führt dann kurz vor Emori zu den seltsamsten Effekten.
Mehrfach hier im Forum nachzulesen.

 

[PeterPawn]

Und die Einstellungen zum verfügbaren Up-/Download stimmen auch bei der Anzeige? Ansonsten findet man in den Support-Daten auch die Aussage (nach "qdisc" suchen), was die Firmware für die max. Upload-Kapazität beim QoS hält (man kann es aber auch mit "tc" selbst abfragen per Shell).

Ich würde eher darauf tippen, daß diese Angaben einfach zu hoch sind für Deinen Anschluß - schon ausreichende CRC-Fehler beim Upstream mit entsprechenden Wiederholungen beeinträchtigen ja den real erzielbaren Durchsatz merklich und machen QoS zur Makulatur, weil natürlich bei prozentualen Reservierungen bzw. bei höher priorisiertem Queueing davon ausgegangen wird, daß da auch eine "reliable transmission" möglich ist und (m.W.) Probleme dort nicht rückgekoppelt werden und zur Verringerung der Basiswerte führen.

Ob man bei Verwendung des internen DSL-Modems die Werte für den US-/DS-Durchsatz überhaupt überschreiben kann, weiß ich nicht - beim Betrieb hinter einem externen Modem gibt es eine entsprechende Einstellung, eben damit die FRITZ!Box das QoS auf der Basis halbwegs realistischer Werte machen kann und auch da ist es dann besser, etwas unter den tatsächlich möglichen Werten zu bleiben, denn die Leitung würde auch dann mit voller Kapazität betrieben, die Box drosselt ja keinen Download. Das kann sie auch nur indirekt über verzögerte Auslieferung von Quittungspaketen und die gehen ja i.d.R. nicht direkt von ihr aus (sondern vom betroffenen LAN-Client), da müßte sie dann entsprechend puffern, wenn sie "regeln" wollte - macht sie (meines Wissens, ich kann immer wieder nur betonen, daß gerade dieser Teil "closed source" ist) aber nicht, bringt ja auch nur wenig in der Praxis - die Mechanismen von TCP sind da viel besser geeignet für solche Aufgaben und die wirken dann aber direkt zwischen Server und Client.

 

[eisbaerin]

"seid einiger Zeit"

Das wird doch, wie in #1 richtig, mit "t" geschrieben.
(einfach sehr schlecht zitiert)

 

[Novgorod]

Früher waren die "Innereien" der 7330 und des Netzteils noch frisch und saftig, inzwischen wohl ausgetrocknet. [...] Das führt dann kurz vor Emori zu den seltsamsten Effekten.

zu welchen effekten? dass bei vollem downstream nicht mehr richtig geroutet wird? :gruebel: das habe ich noch nie im zusammenhang mit einem zu schwachen netzteil gesehen..
überhaupt ist die box eigentlich nicht instabil, sondern verhält sich wie jede billig-fritzbox, d.h. wie ein alter windows-98-rechner (und das trotz linux ) - wird die uptime zu lang, müllt die box sich zu.. neustarts habe ich ab und zu beobachtet, wenn sich nach langer uptime (wochen) das webinterface aufhängt, und zwar beispielsweise genau in dem moment wenn man sich versucht einzuloggen (da passiert dann ~30 sekunden lang nix, gefolgt von einem neustart) - das verursacht sicher nicht das netzteil, sondern irgendein watchdog, der sieht, dass sich eine anwendung aufgehängt hat.. frisch nach dem neustart läufts für ein paar tage halbwegs "flüssig" (wenn man bei der fritzbox-bedienung davon sprechen kann), unabhängig von CPU-last.. ich habe auch eigentlich noch nie einen neustart beobachtet, ohne dass irgendwas im webinterface gemacht wurde..

Und die Einstellungen zum verfügbaren Up-/Download stimmen auch bei der Anzeige? Ansonsten findet man in den Support-Daten auch die Aussage (nach "qdisc" suchen), was die Firmware für die max. Upload-Kapazität beim QoS hält (man kann es aber auch mit "tc" selbst abfragen per Shell).

du meinst die DSL-anzeige? da steht momentan 16,2MBit/s down und 1,1MBit/s up (der download variiert von tag zu tag zwischen ~15,5MBit/s und ~17,2MBits).. auch im online-monitor ist die geschwindigkeitsanzeige beim downloaden mit voller bandbreite korrekt und stimmt auch mit dem überein, was der PC tatsächlich bekommt.. die suche nach "qdisc" bringt nichts, was für mich aufschlussreich wäre (das ist der einzige block, wo es auftaucht):

qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 7187449 bytes 31831 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc tbf 2: dev adsl root refcnt 2 rate 1138Kbit burst 3679b lat 646us 
 Sent 167285265 bytes 1420045 pkt (dropped 10426, overlimits 209763 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc llq 10: dev adsl parent 2: minq 1 maxq 255 default 6
 Sent 168434809 bytes 1430471 pkt (dropped 10426, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 104: dev adsl parent 10:4 limit 32p quantum 100b perturb 10sec 
 Sent 6857004 bytes 10894 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 105: dev adsl parent 10:5 limit 32p quantum 100b perturb 10sec 
 Sent 99861119 bytes 1204795 pkt (dropped 9688, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 106: dev adsl parent 10:6 limit 32p quantum 100b perturb 10sec 
 Sent 59623559 bytes 180367 pkt (dropped 738, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 107: dev adsl parent 10:7 limit 32p quantum 100b perturb 10sec 
 Sent 151086 bytes 457 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev dsl root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 10737500 bytes 72432 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev wifi0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 39329046 bytes 40564 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev ath0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 14577300 bytes 78599 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0

Ich würde eher darauf tippen, daß diese Angaben einfach zu hoch sind für Deinen Anschluß - schon ausreichende CRC-Fehler beim Upstream mit entsprechenden Wiederholungen beeinträchtigen ja den real erzielbaren Durchsatz merklich und machen QoS zur Makulatur, weil natürlich bei prozentualen Reservierungen bzw. bei höher priorisiertem Queueing davon ausgegangen wird, daß da auch eine "reliable transmission" möglich ist und (m.W.) Probleme dort nicht rückgekoppelt werden und zur Verringerung der Basiswerte führen.

am upstream kann es eigentlich nicht liegen, er ist beim download mit voller bandbreite nur zu ~30% ausgelastet.. wie kann man denn zuverlässig testen, ob die QoS-einstellungen passen?

 

[PeterPawn]

Die Ausgabe von "tc -s qdisc show" (das ist das von Dir oben gezeigte) steht im Widerspruch zu Deiner Aussage, der Upload wäre nur zu 30% ausgelastet.

qdisc tbf 2: dev adsl root refcnt 2 rate 1138Kbit burst 3679b lat 646us 
 Sent 167285265 bytes 1420045 pkt (dropped 10426, overlimits 209763 requeues 0)

Die Statistik zeigt, daß von den 1420045 dort ankommenden Paketen 10426 gar nicht erst in die Warteschlange eingereiht werden konnten, weil die zu diesem Zeitpunkt schon voll war und weitere 209763 Pakete wurden vom Traffic-Shaping verzögert, weil sie das Limit auf der ADSL-Leitung überschritten hätten, wenn sie sofort weitergeleitet worden wären.

Wenn Dir die FRITZ!Box bei diesen Werten nur 30% Auslastung Deines Uploads von 1,1 MBit/s anzeigt, dann ist entweder die Anzeige oder die Paketzählung der Queue-Manager falsch. Wenn von 1420045 Paketen 209763 vom tbf verzögert werden (knapp 15 %), dann sollte eine korrekte Anzeige auch mind. zu 15% der Zeit am oberen Anschlag sein, sonst stimmt etwas mit der "Auslaufgeschwindigkeit" des Eimers für den DSL-Anschluß nicht, was mich dann wieder zu der Frage nach der Leitungsqualität führt. Wenn Du nichts an den Einstellungen des QoS geändert hast, sieht das etwas merkwürdig aus.

Ich weiß zwar auch nicht genau, was vom FRITZ!OS wie klassifiziert wird (und habe auch keinen Bock, das jetzt zu erkunden), aber bei 168434809 Bytes in 1430471 Paketen (durchschnittlich knapp 120 Byte pro Paket) können das kaum alles nur TCP-ACKs sein, die sind i.d.R. nur etwa halb so groß (50-70 Byte, je nachdem wo man zählt und welches Protokoll im TCP transportiert wird, was dann entsprechende "Nutzdaten" noch in die ACK-Pakete einbetten kann) - was dann natürlich die Frage aufwirft, wie groß die anderen Pakete sind, die diesen Durchschnitt so weit nach oben treiben ... denn für jedes per TCP empfangene Paket gibt es ja ein solches TCP-ACK. Das heißt dann schon, daß auf ein TCP-ACK-Paket mit 60 Byte mindestens ein anderes Paket mit 180 Byte kommen muß, damit der Durchschnitt wieder stimmt und da es eben sehr viele solcher ACK-Pakete gibt, braucht es entweder viele solcher 180 Byte-Pakete oder weniger noch größere Pakete, damit dieser Durchschnitt wieder erreicht wird. Da ist also parallel zu einem simplen HTTP-Download noch anderes im Upload aktiv - das kann alles mögliche sein, selbst ein IP-Telefonat und da das ja keine aktuellen Werte sind, sondern eine "overall statistic", ist das nicht richtig zu sehen.

Aber trotzdem ... nicht mehr als 30% Auslastung passen nicht zu den qdisc-Statistiken, eines von beidem kann nicht stimmen. Was genau jetzt in welche Queue für "stochastic fairness queueing" (sfq) eingereiht wird (105 hat knapp 10000 "dropped packets" und 106 nur 738 davon, aber weg ist nun mal weg und kommt - außer bei TCP - auch nicht wieder), wäre die Frage ... bei TCP-Verbindungen sollten solche Paketverluste die Datenrate von alleine effektiv herunterregeln (wenn man nicht an den Client-Einstellungen "dreht" - manche halten das ja für "Optimierungen" ... damit hat der Router ja nichts zu tun, daß ist oberhalb seines Kompetenzlevels) und warum die Ausgangsqueue so vollaufen kann, daß da gedroppt werden muß, wenn die Leitung doch in Ordnung ist, verstehe ich auch nicht so ganz.

Mein Upload verkraftet 5 MBit/s und der tbf sieht so aus:

qdisc tbf 2: dev ptm_vr9 root refcnt 2 rate 5005Kbit burst 16178b lat 646us
 Sent 2128873313 bytes 1838140 pkt (dropped 1052, overlimits 1730301 requeues 0)
 backlog 0b 0p requeues 0

Da war allerdings für die Zeit des Uploads von knapp 2 GB die Leitung auch bei 100% Auslastung und trotzdem habe ich (113.06.50) nur 10% der Paketverluste im Vergleich zu Dir, obwohl man auch deutlich sieht, daß der Queueing-Algorithmus fast alle Pakete (1730301 von 1838140 gesamt) verzögert hat, weil sonst die Rate überschritten worden wäre. Dabei kann man aber andere Dienste wunderbar weiterhin nutzen, denn eigentlich sollten die vorgeschalteten (oder auch danach, je nachdem, wie man es sehen will) sfq-Queues ja (per Hashing über Adressen und Ports) dafür sorgen, daß nicht eine einzelne Verbindung die gesamte verfügbare Bandbreite belegt, weil das per Round-Robin zwischen den "hash buckets" einer solchen Queue verteilt werden sollte - wobei nicht alle Queues so einen sfq-Scheduler "vorgeschaltet" haben (Parameter "with_sfq" in der ar7.cfg).

Halb OT: Wobei ich mir bei deren Wirksamkeit auch etwas unsicher bin, denn der reinen Theorie nach sollte die "quantum"-Angabe einer solchen Queue (das ist die Anzahl der zu verarbeitenden Bytes eines Buckets, bevor das nächste an der Reihe ist) eigentlich nicht niedriger sein als die maximale mögliche Paketgröße (MTU), damit ein komplettes Paket verarbeitet werden kann. Wenn ich die Theorie dahinter hier richtig interpretiere (man kann ja nicht in die Quellen schauen, was da passiert, wenn das vorne im Bucket stehende Paket größer ist als die 100 Byte, die erlaubt sind), würde das erste Paket nur dequeued und gesendet, wenn es selbst kleiner als diese 100 Byte ist (oder es könnte natürlich auch sein, daß es immer mindestens ein ganzes Paket ist, was da bis zum Ende verarbeitet wird, wenn es erst einmal angefaßt wurde und daß dafür der Parameter "allow_more" aus der ar7.cfg zuständig ist). Das könnte in der Tat aber auch dazu führen, daß erst einmal alle Buckets mit kleinen Paketen am "Boden" des Eimers (wo das Loch zum "Auslaufen" ist) zum Zuge kommen (ein normales ACK-Paket würde da eben hineinpassen in diese 100 Byte) und erst dann die größeren Pakete ausgeliefert werden. Was da nun genau abläuft, ist schwer abzuschätzen, weil ja am "dev dsl" gerade nicht der normale Linux-IP-Stack zum Einsatz kommt, sondern eine AVM-eigene Implementierung.

Das ist ohnehin ein elendes Gepuzzle, die Ausgaben des kdsld (via /proc/kdsld/nqos) mit den Queue- und Classifier-Definitionen in der ar7.cfg in Deckung zu bringen. Zumal da AVM auch noch zusätzlich Klassifizierungen offenbar direkt in der Firmware verankert, denn eine Entsprechung für die Regel "udp.dport 5060 packetmatch *sip:*@tel.t-online.de* (sip) => 9" bei der 7490 findet sich nirgendwo in der ar7.cfg - das ist alles ein "Gefrickel", daß sich einem die Fußnägel aufrollen.

Aber ich würde bei Dir nach wie vor entweder auf Probleme beim Senden tippen (das sollte man in den DSL-Statistiken sehen können), womit dann die Queue nicht auf die angegebene Rate kommt oder auf falsche Änderungen an den QoS-Einstellungen, womit jetzt Daten in einer Queue landen, wo sie nicht hingehören.

Wenn man einen fehlerbehafteten Upload sicher ausschließen kann, sollte man noch einmal einen Blick auf die ar7.cfg (den gesamten nqos-Abschnitt), die Ausgabe von "cat /proc/kdsld/nqos/*" und die Queue-Statistiken werfen, aber dann bei einer relativ frisch gebooteten Box, bei der man außer dem Download-Test noch nichts großartig weiter unternommen hat, damit die Zähler die Fehlersituation und nicht irgendwelche Langzeitstatistiken widerspiegeln und dann braucht es auch die genaue Angabe, was dabei im Netz passiert sein sollte, damit man den Verkehr bei den Klassifizierungen nachvollziehen kann. Normalerweise sollten ICMP-Pakete (Du schreibst ja auch, daß "ping" nicht funktionieren würde) direkt in einer Queue namens "hprio" landen, das müßte nach der Queue "ifacectl" die am höchsten priorisierte sein (precedence=10) und die arbeitet auch noch ohne sfq-Scheduler davor. Da ist es schon extrem komisch, wenn nicht einmal ein solches ICMP-Paket seinen Weg ins Internet finden soll. Eine Antwort der Gegenstelle sollte in jedem Falle ja im Download auftauchen, wenn sie von dort überhaupt gesendet wurde. Wenn die schon vor der FRITZ!Box gedroppt werden sollte, wäre auf der Providerseite etwas mit den Einstellungen nicht in Ordnung.

 

[thtomate12]

Ist im Log der FB nach Verbindungsaufbau einen Eintrag über "reale Bandbreite vom Provider"?

 

[Novgorod]

@PeterPawn: erstmal danke für die ausführliche antwort und sorry für die späte rückmeldung - ich bin gerade nicht daheim und kann erst am mittwoch mit der fritzbox weitertesten.. nur soviel vorweg zum upload: beim download mit voller bandbreite (1,5-1,7Mbyte/s) zeigt mir der traffic-monitor am client nicht mehr als 40kbyte/s upload an.. beim "echten" upload einer datei bekomme ich immer die vollen 120kbyte/s, daher die 30% upload-auslastung mit bestätigungspaketen beim download.. es sollte doch eigentlich nicht sein, dass die brutto-uploadrate während eines fullspeed-downloads irgendwie eingeschränkt wird .. ich denke eher, dass das problem am download liegt, wenn nicht einmal ping-pakete zurückkommen.. ich werde auch nochmal testen, ob die leitung auch bei vollem upload blockiet oder nur beim download..