[Frage] QoS mit Freetz

[JulPal]

1. Bei der 16000 Leitung war FastPath geschalten, im besten Fall hatte ich über LAN einen Ping von 11/12ms zum Google Server.
Bei der jetzigen 6000 ist kein FastPath mehr geschalten, im besten Fall habe ich jetzt über LAN einen Ping von 43/44ms zum Google Server.
Hier die Latenzangaben aus der FritzBox:
Empfangsrichtung: 16 ms
Senderichtung: 16 ms

2. Sorry, wurde editiert

 

[PeterPawn]

@JulPal:
2. Danke.

1. Dann tut es mir leid, aber die Latenz aufgrund des Interleaving (betrifft aber nur den Download m.W.) kriegst Du mit keinem QoS der Welt weg. Event. schaltet der Anbieter ja wieder auf FastPath um, wenn Du dort nachhakst. Früher (aber wirklich nur früher) wollte man dafür noch extra kassieren, würde ich mich heute nicht mehr drauf einlassen.

 

[xrated]

Vielleicht interessiert den einen oder anderen doch noch bez. echten QoS

In den älteren Versionen konnte man das anscheinend noch per Menü ausschalten:

Das ganze steckt wohl in der avm firewall bzw. dsld. Würde mal vermuten das es reicht es in rc.conf zu deaktivieren:
export CONFIG_NQOS="n"
export CONFIG QOS_METER="n"
Siehe auch:
https://github.com/olistudent/freetz/blob/master/patches/scripts/315-remove-qos.sh

Leider kann ich die rc.conf nicht editieren (nur readonly). Geht das nicht? Ansonsten muss man wohl den qos remove patch ändern das nur die rc.conf geändert wird.

Etwas unklar ist mir noch wieso man bei Kernel Modules die ganzen net Scheduler zusätzlich auswählen kann wenn die eigentlich schon im Fritz OS mit dabei sind. War das bei älteren Kernelversionen nicht der Fall?

 

[PeterPawn]

Und hier bin jetzt ich "lost in translation" ... :gruebel:

Das ganze steckt wohl in der avm firewall bzw. dsld. Würde mal vermuten das es reicht es in rc.conf zu deaktivieren:
export CONFIG_NQOS="n"
export CONFIG QOS_METER="n"

Wie kommst Du darauf, daß der TE den "remove QoS"-Patch überhaupt angewendet hat, wenn er doch in #5 schreibt:

Und ja, die Priorisierung ist bei der 54.04.89 schon von Haus aus drin, habe mich auch schon damit befasst. Aber bringt in dem Fall leider gar nichts.

Leider kann ich die rc.conf nicht editieren (nur readonly). Geht das nicht?

Nein, das geht natürlich nicht so ohne weiteres. Bei so ziemlich jeder Firmware-Version für die FRITZ!Box (Ausnahme usbroot bei Freetz bzw. event. ein selbstgebasteltes Filesystem-Modell mit Overlays) liegt diese Datei in einem SquashFS-Image, das als root-Filesystem gemountet wird. Ein SquashFS-Image ist per Definition read-only.

Ansonsten muss man wohl den qos remove patch ändern das nur die rc.conf geändert wird.

Wieso sollte man das Ausschalten der Umgebungsvariablen für QoS in einem Patch ändern, wenn dieser gleichzeitig auch noch die für QoS benötigten weiteren Bestandteile aus der Firmware entfernt. Das einzige Ergebnis wäre doch, daß seitens der Firmware dann versucht würde Funktionen zu aktivieren, die überhaupt nicht mehr im Image enthalten sind.
Der Sinn des Patches ist es doch nicht, das QoS in der Firmware ein- oder auszuschalten ... der erlaubt dem Benutzer nur, für den Fall von fehlendem Platz im Freetz-Image auf die QoS-Funktionen komplett zu verzichten. Solange es im Image enthalten ist, kann man es natürlich immer noch ausschalten ... aber logischerweise nicht einschalten, wenn es gar nicht vorhanden ist.

 

[xrated]

Wie kommst Du darauf, daß der TE den "remove QoS"-Patch überhaupt angewendet hat

wer hat das behauptet?

Wieso sollte man das Ausschalten der Umgebungsvariablen für QoS in einem Patch ändern, wenn dieser gleichzeitig auch noch die für QoS benötigten weiteren Bestandteile aus der Firmware entfernt.

Du hast nicht richtig verstanden, den Patch so modifizieren das eben nicht alles entfernt wird was QoS betrifft sondern nur das was AVM konfiguriert so das man später seine eigenen Rules definieren kann mittels tc+iptables.
Also quasi ein remove avmqos.
Danach kann man sowas machen, besser noch mit L7:
http://www.networx-online.de/networ...-unter-linux-prio-basierend-fair-queuing.html

 

[PeterPawn]

Du hast nicht richtig verstanden, den Patch so modifizieren das eben nicht alles entfernt wird was QoS betrifft sondern nur das was AVM konfiguriert so das man später seine eigenen Rules definieren kann mittels tc+iptables.

Das erklärt ja immer noch nicht, warum ich (man) den Patch überhaupt anwenden sollte, wenn man das QoS gar nicht entfernen möchte. Will man das AVM-QoS nicht benutzen, schaltet man es halt ab ... was man dann an eigener Klassifizierung macht, hat damit ja zunächst mal nichts zu tun.

Also quasi ein remove avmqos.

Eben genau darunter kann ich mir nichts vorstellen. Das ganze Gebilde besteht (etwas vereinfacht) aus den folgenden Zutaten:

1. einer Klassifizierung des zu routenden Verkehr (wichtig, kann warten, eilt, usw.), im Büro ist das die Sekretärin, die den Poststrom für den Chef "vorsortiert" und in verschiedene Mappen einordnet (Queues)

2. einem Scheduler, der nach bestimmten Kriterien aus diesen Queues die nächsten zu übertragenden Daten auswählt

3. einem Interface, in dem man für die Klassifizierung und das Scheduling einige Einstellungen vornehmen kann

Das Interface sieht bei der Firmware des TE z.B. so aus:
Anhang anzeigen 78946Anhang anzeigen 78947Anhang anzeigen 78948

Der "interne" Teil (also Classification/Queuing/Scheduling) erfolgt bei AVM wohl schon mit 'tc', jedenfalls sind auf der 7270v1 folgende qdiscs definiert:

# tc qdisc
qdisc pfifo_fast 0: dev cpmac0 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 2: dev wan rate 1172Kbit burst 3787b lat 10.3ms
qdisc llq 10: dev wan parent 2: minq 1 maxq 255 default 6
qdisc sfq 104: dev wan parent 10:4 limit 32p quantum 100b perturb 10sec
qdisc sfq 105: dev wan parent 10:5 limit 32p quantum 100b perturb 10sec
qdisc sfq 106: dev wan parent 10:6 limit 32p quantum 100b perturb 10sec
qdisc sfq 107: dev wan parent 10:7 limit 32p quantum 100b perturb 10sec
qdisc pfifo_fast 0: dev eth0 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev dsl bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Nun kann man sich sicherlich eine noch feiner granulierte Klassifizierung wünschen ... aber das ändert ja am Prinzip nichts, wenn es neben "eilt" noch ein "eilt sehr" gibt. Außerdem kann man mit geeigneten Einstellungen in der ar7.cfg auch weitere Filter für die Klassifizierung "nachrüsten".

Welchen Teil des Gesamtpakets (1. - 3.) würdest Du denn mit dem "remove avmqos" entfernen wollen ?

Danach kann man sowas machen

Wo besteht da der Unterschied zur AVM-Version genau ? Was kann iptables besser, was die nqos-Einstellungen von AVM nicht auch könnten und was in einem Internet-Router sinnvoll ist ?

besser noch mit L7

Also bei allem Optimismus ... eine Inspektion auf Layer7 mit einem UR8 in einem Speedport W501V ?

Das ist sicherlich auch eine Möglichkeit, den Traffic effektiv zu drosseln, allerdings sehe ich nicht so richtig, wie man den vom TE erwünschten Traffic vor dieser Inspektion bewahren soll.

 

[xrated]

Warum bist du der Meinung das es hier nur um den W501 und TE gehen muss? Der Threadtitel ist allgemein gehalten.
Eine aktuelle 7390 oder 7490 sollte locker für L7 reichen wenn conntrack aktiv ist.
Ich schreibe hier auch nicht ganz uneigennützig. Und nachträglich QoS deaktivieren ist bei aktuellem Fritz OS eben nicht mehr so einfach, aber das schrieb ich bereits.
Bei den Regeln von AVM weiß auch kein Mensch wie das ganze genau konfiguriert ist, quasi eine Blackbox. Was ich bisher gelesen habe so scheint die Lösung von AVM auch nicht so toll zu funktionieren. Und mit iptables hat man halt einiges mehr an Möglichkeiten.

 

[PeterPawn]

@xrated:
Ich habe mich auch geirrt, es geht gar nicht um einen W501V, sondern um einen W503V ... deshalb auch die 7270v1 als Alien, der W501V braucht m.E. eine 7170-Version.

Offenbar ist es an mir vorübergegangen, daß Du eine allgemeine Diskussion zum QoS in AVM-Firmware vs. QoS in Freetz führen wolltest/willst, denn auch wenn der Thread-Titel vom TE etwas allgemein gehalten wurde, steht ja in #1 eindeutig, worum es ihm ging.

Ich bin aber gerne bereit, mit Dir in einen neuen Thread auch darüber zu diskutieren

Vielleicht interessiert den einen oder anderen doch noch bez. echten QoS

, was ein "echtes" von einem "unechten" QoS unterscheidet und was das Verhalten von uralten Firmware-Versionen (der Screenshot aus #43 dürfte noch von einer Box mit 2.4er-Kernel stammen) mit der Möglichkeit der Abschaltung des AVM-QoS und dem "remove patch" aus Freetz (oder dem aus dem fork/der Kopie auf github) zu tun hat.

Da Du dich erheblich über die Unmöglichkeit der Änderung der rc.conf wundertest, dachte ich ursprünglich, Du wärst auf der Suche nach Hilfe mit einem konkreten Problem, wie es der TE war/ist.

Wenn Du Dich über die verschiedenen Möglichkeiten der Erweiterung/des Ersatzes des AVM-QoS-Managements durch alternative Lösungen austauschen willst, habe ich damit auch kein Problem, aber es ging - zumindest für mich - nicht eindeutig aus dem Beitrag hervor und ich wollte nur verhindern, daß der TE in der Hoffnung, es würde ihn bei seinem W503V weiter bringen, zusätzliche Arbeit investiert in das Modifizieren des "remove patch" für QoS, solange Du keine konkreten Vorschläge zur Änderungen des Patches gemacht hast.

Ich habe z.B. immer noch nicht begriffen, ob Du nun mit

Das ganze steckt wohl in der avm firewall bzw. dsld. Würde mal vermuten das es reicht es in rc.conf zu deaktivieren:
export CONFIG_NQOS="n"
export CONFIG QOS_METER="n"

das AVM-QoS eher aktivieren, deaktivieren oder nur teilweise ersetzen willst/wolltest oder was Du uns ansonsten damit sagen wolltest.

Sorry, ist nicht böse gemeint, nur für mich ist/war die damit verbundene Intention nicht ersichtlich. Und dann frage ich eben nach ... das kann ja nicht verboten sein.

Und nachträglich QoS deaktivieren ist bei aktuellem Fritz OS eben nicht mehr so einfach, aber das schrieb ich bereits.

Das habe ich so nicht gelesen ... aber vielleicht habe ich es ja auch nur nicht verstanden. Allerdings bin ich aus

Du hast nicht richtig verstanden, den Patch so modifizieren das eben nicht alles entfernt wird was QoS betrifft sondern nur das was AVM konfiguriert so das man später seine eigenen Rules definieren kann mittels tc+iptables.
Also quasi ein remove avmqos.

auch nicht recht schlau geworden ... das habe ich imho auch nicht verschwiegen. Ich will auch nicht unbedingt auf Klugscheißer machen, aber im Satz "Komm wir essen Opa." fehlt auch ein Komma, das - je nach Position - dem Satz einem komplett anderen Sinn verleiht und so geht es mir mit dem oben zitierten irgendwie auch. Aus diesem werde ich auch nicht schlau:

Das verstehe ich auch warum hier soviel über Proxy geschrieben wird wenn man das Problem weiter oben angehen könnte.

Wenn es Deine Vermutung ist, daß zur Deaktivierung des AVM-QoS auch das Setzen der entsprechenden Environment-Variablen ohne das Entfernen der anderen Zutaten ausreichend ist und Du diese These überprüfen willst (das ist eine mögliche Interpretation dessen, was Du vorher geschrieben hast), kannst Du das ganz einfach mit einem

echo "CONFIG_NQOS=x" >>/var/flash/featovl.cfg
echo "CONFIG_QOS_METER=x" >>/var/flash/featovl.cfg

testen, solange es keine Kabel-Box ist ... das sollte sogar mit originaler AVM-Firmware funktionieren, wenn das wirklich alle Environment-Variablen sind, aus denen die Firmware die Entscheidung für oder gegen die Aktivierung des QoS ableitet.

Wenn das dann nicht oder nicht wie erwartet funktioniert, kann man mit einem "echo -n >/var/flash/featovl.cfg" das "Überlagern" auch wieder rückgängig machen.

(In den Kommandos oben das x natürlich mit y oder n ersetzen, je nachdem, was Du da am Ende der Abarbeitung der rc.conf sehen willst als Einstellung.)

 

[xrated]

Merkwürdig, beim ersten Versuch klappte das mit der featovl.cfg. Dann nach Reboot wollte ich die Settings ändern und es gelingt mir nicht mehr die Default Settings abzuändern. Die Binary boxfeaturedisable gibts auf der W701V(7170) auch nicht.
Die Datei featovl.cfg ist standardmäßig auch nicht vorhanden.

 

[PeterPawn]

Die Binary boxfeaturedisable gibts auf der W701V(7170) auch nicht.

Ja, die ist erst später entstanden (vermutlich mit den DOCSIS-Boxen, wo sie wohl auch nur eingesetzt wird). EDIT: Ist auch ein Shell-Skript in aller Regel, das genau nichts anderes macht, als die featovl.cfg zu schreiben. Wie es aussieht, kann man sich in einer aktuellen Firmware ansehen.

Dann nach Reboot wollte ich die Settings ändern und es gelingt mir nicht mehr die Default Settings abzuändern.

Das ist als Feststellung verstanden, als "Hilferuf" etwas schmal an Inhalt.

Die Datei featovl.cfg ist standardmäßig auch nicht vorhanden.

Das kommt darauf an, was man unter "nicht vorhanden" versteht. Die featovl.cfg ist ein übliches Konfigurationsfile im TFFS und als solches ein char-Device. Sie wird als char-Device sehr früh im Rahmen des Bootvorgangs erstellt (S01-head, aber ohne Garantie, habe grade keine Lust, das zu verifizieren), hat aber keinen Inhalt. Viele, die sich mit der Natur des TFFS nicht auseinandergesetzt haben, interpretieren eine "file not found"-Meldung nach einem "cat" auch mal als "Datei nicht vorhanden", richtig wäre "Datei hat keinen Inhalt". AVM prüft solche Sachen i.d.R. vor dem Zugriff mit "checkempty". Eine mit "echo -n" und Redirection geleerte "Datei" ist auch im Sinne von "checkempty" leer, "cat" liefert aber keinen Fehler. Nach einem "echo clear_id minor_id >/proc/tffs" liefert "cat" wieder das "fnf".

root@FB7490:~ $ ls -la /var/flash/crash.log
crw-rw----    1 root     root      243,  95 Nov 22 18:37 /var/flash/crash.log
root@FB7490:~ $ cat /var/flash/crash.log
cat: can't open '/var/flash/crash.log': No such file or directory
root@FB7490:~ $ checkempty /var/flash/crash.log; echo $?
checkempty: : No such file or directory
0
root@FB7490:~ $ checkempty /var/flash/ar7.cfg ; echo $?
1
root@FB7490:~ $ echo "abc" >/var/flash/crash.log
root@FB7490:~ $ cat /var/flash/crash.log
abc
root@FB7490:~ $ checkempty /var/flash/crash.log; echo $?
1
root@FB7490:~ $ echo -n >/var/flash/crash.log
root@FB7490:~ $ cat /var/flash/crash.log
root@FB7490:~ $ checkempty /var/flash/crash.log; echo $?
0
root@FB7490:~ $ echo clear_id 95 >/proc/tffs
root@FB7490:~ $ checkempty /var/flash/crash.log; echo $?
checkempty: : No such file or directory
0
root@FB7490:~ $ cat /var/flash/crash.log
cat: can't open '/var/flash/crash.log': No such file or directory
root@FB7490:~ $

 

[xrated]

Die Datei wird beim Reboot gelöscht

 

[PeterPawn]

Die Datei wird beim Reboot gelöscht

Das mag ja für eine bestimmte Firmware-Version und ein bestimmtes Modell zutreffen, ist aber nicht allgemeingültig. Insofern wäre eine exakte Angabe, für welches Modell und welche Firmware-Version Du dieses festgestellt hast (ggf. mit einer Erwähnung, wer für das Löschen verantwortlich ist bzw. es ausführt), hilfreich.

Bei einer 7390/7490 (jeweils mindestens seit der 06.xx-Firmware) bleibt der Inhalt der featovl.cfg über einen Reboot hinaus erhalten.

Bei den DOCSIS-Modellen 6360 und 6490, wo per SNMP unter Zuhilfenahme dieses Files vom Provider bestimmte Dienste der FRITZ!Box ein- und ausgeschaltet werden können, findet sogar bei einer Differenz zum alten Inhalt (per MD5-Hash getestet) nach dem Schreiben des neuen Inhalts der featovl.cfg direkt ein Reboot statt bzw. nach dem Start des ctlmgr, wenn die Änderung der featovl.cfg bereits vor dem Start des ctlmgr erfolgt sein sollte (Zeile 53 in /bin/boxfeaturedisable, das in so ziemlich jeder Firmware ab 06.xx für jedes Modell enthalten sein sollte, aber wohl nur bei DOCSIS-Modellen aufgerufen wird).

Wenn dabei der neue Inhalt der featovl.cfg jedesmal auf's Neue verloren gehen würde, verlöre die featovl.cfg dort vollkommen ihren Sinn.

Eine solche Box endete letzten Endes auch in einer Reboot-Schleife, wenn nach der DOCSIS-Provisionierung das Skript "boxfeaturedisable" von "docsis_feature_disable" aufgerufen würde, ohne daß die dabei ausgewählten und gespeicherten neuen Einstellungen einen Neustart überleben, da dann ständig eine Differenz zur gespeicherten featovl.cfg vorhanden wäre (Zeile 38 in boxfeaturedisable).

 

[xrated]

(ggf. mit einer Erwähnung, wer für das Löschen verantwortlich ist bzw. es ausführt), hilfreich.

Woher soll ich das wissen?

Es ist wie oben schon erwähnt eine W701V zur 7170 umgeflasht und mit freetz 2.0 stable.

Wenn es bei dem alten Ding nicht geht dann werde ich eben nqos und dsld komplett rauspatchen. Ist erstmal eh nur als Testgerät gedacht um im LAN als QoS Router zu fungieren.

 

[PeterPawn]

Woher soll ich das wissen?

Deshalb steht da "ggf.", normalerweise als "gegebenenfalls" gelesen und die Liste der möglichen Synonyme findest Du sicherlich selbst.

Es ist wie oben schon erwähnt eine W701V zur 7170 umgeflasht und mit freetz 2.0 stable.

Auch wenn Du das sicherlich anders siehst, es ist das erste Auftauchen dieser Auskunft hier im Thread ... aus dem vorherigen

Die Binary boxfeaturedisable gibts auf der W701V(7170) auch nicht.
Die Datei featovl.cfg ist standardmäßig auch nicht vorhanden.

geht das nämlich keinesfalls so deutlich hervor ... genauso wenig wie die Tatsache, daß Du offenbar den stable-2.0-Branch von Freetz verwendest. Über die zwei anderen Irrtümer in den zitierten Text (boxfeaturedisable als Binary und Vorhandensein der featovl.cfg) haben wir hoffentlich schon eine Einigung erzielt.

Mein Hinweis auf die Möglichkeit einer temporären Überlagerung von Einstellungen in der Firmware durch die featovl.cfg kam auch zu einem Zeitpunkt, wo es nach Deinem Willen nicht mehr um einen "gefreetzten" Speedport-Router gehen sollte:

Eine aktuelle 7390 oder 7490 sollte locker für L7 reichen wenn conntrack aktiv ist.
Ich schreibe hier auch nicht ganz uneigennützig.

Daraus kann man ja wohl unmittelbar schließen, daß für Dich persönlich die Modelle 7390 und 7490 von Bedeutung sind.

Danach landest Du in #49 dann wieder bei einem Speedport-Router, der sogar nur zu einem noch älteren FRITZ!Box-Modell kompatibel ist (W503V des TE -> 7270, Dein W701V -> 7170).

Jetzt warte ich nur noch darauf, daß ich am Ende daran Schuld trage, daß bei der 7170 die gesamte Behandlung der featovl.cfg überhaupt noch nicht in der rc.conf enthalten ist.

Damit wird die featovl.cfg auch nicht beim Reboot gelöscht, sie wird ganz simpel nach einem Neustart nicht angelegt in rc.S (die Aufteilung auf mehrere Startskripte kam erst später in der AVM-Firmware).

Das kann man jetzt als Paradebeispiel für Mißverständnisse nehmen, die sich aus unvollständigen/widersprüchlichen Informationen bei Stellen von Fragen ergeben oder meinetwegen auch beim Veröffentlichen von irgendwelchen Lösungen. Deshalb wirst Du bei mir in aller Regel auch eine Angabe finden, für welche Firmware-Version (und auch noch welches Modell, wenn das eine Rolle spielt) meine Behauptungen gelten ... wenn es nicht ohnehin aus dem Kontext schon hervorgeht.

Ich weiß inzwischen nicht mehr genau, was Du mir am Ende sagen willst ... insofern mische ich mich hier nicht länger ein.

 

[JulPal]

Also, erstmal vielen vielen Dank für die vielen Antworten.
Leider sind wir ja nach 3 Seiten immer noch zu keinem funktionierenden Ergebnis gekommen.
Ich habe jetzt auch nochmal lange das Forum nach QoS durchsucht, und nirgends eine Lösung gefunden.
Ich habe mich jetzt dafür entschieden einfach einen Router mit QoS/Traffic Shaping zu kaufen.
Schade, dass es hier im Forum keine funktionierende Lösung gibt.
Nochmal vielen Dank für eure Bemühungen.
Gruß Julian