[Problem] 6490 am Glasfaseranschluss = QoS für den Eimer...

karl001

Neuer User
Mitglied seit
3 Okt 2005
Beiträge
51
Punkte für Reaktionen
0
Punkte
6
Hallo Zusammen,

ich bin gerade etwas auf 180 weil der AVM Support mich mal fröhlich hat abblitzen lassen, was da heute passiert ist spottet jeglicher Beschreibung...

Generell zum Ablauf:

Ich betreibe eine 6490 per "Internetzugang via LAN1" an einem symmetrischen FTTH Anschluss mit 200Mbit.
Soweit funktioniert alles bis auf das QoS... Der Upstream ist immer auf 99999Kbit begrenzt egal ob ich die 200000kbit als Wert um Upload eingebe oder nicht, er wird immer auf diesen Wert gekürzt.
Selbst ein Export/Reimport der Config mit dem richtigen Wert bringt mal gar nichts, die Box ändert stur auf den geringeren Upstream.
Für mich ist das ein Bug weil man hier nur die maximal Werte des Kabelmodems im Sinn hat, nicht aber den LAN1 Betrieb direkt im LAN.

Was tun sprach Zeus? AVM lässt mich gerade eiskalt abblitzen weil der Betrieb via LAN1 "unsupported" ist, das kann ich nur leider nicht akzeptieren wenn die Box diese Option offiziell in der GUI anbietet, wie seht ihr das?

Schon sehr merkwürdig das der LAN1 Betrieb auch offiziell in der Wissensdatenbank steht:

https://avm.de/service/fritzbox/fri...x-fuer-Betrieb-mit-anderem-Router-einrichten/


Hat jemand eine Idee wie ich der Box den Uploadwert beibringe bzw. QoS als Notlösung abschalte? Fände es ziemlich blöd auf 50% meines Upstreams zu verzichten weil die Box nicht mitspielt...


Dan
 
Zuletzt bearbeitet:
Welche firmware version hast Du denn?
Du hast nicht zufaellig shell zugang? Eventuell ist das eine traffic control/qdisc Regel auf dem Atom (denn nur der sollte im LAN1 Betrieb relevant sein), obwohl ich mich meine zu erinnern dass dort keine installiert waren. Das kann im LAN1 betrieb natuerlich anders sein (das kann ich leider bei mir nicht testen).
Wobei ich glaube dass diese Einstellungen ("tc qdisc show") auch in den supportdaten stehen (mal nach qdisc suchen).

Edit: lag falsch, natuerlich limitiert auf dem atom ein qdisc rule die upload bandbreite. Bei kabel gemaess der gebuchten Bandbreite:
Code:
# /sbin/tc qdisc show
...
qdisc tbf 2: dev eth_udma0 root refcnt 2 rate 3960Kbit burst 12799b lat 640us
...

Waere interessant was da bei LAN1 eingestellt ist.
 
Zuletzt bearbeitet:
Hallo fesc,

leider habe ich keinen Telnetzugang, ich bin mir etwas unschlüssig wie ich die Informationen hier im Forum so zusammen setzte ohne meine Box zu bricken, hast du event. für die Firmware 6.87 auf der 6490 einen Tip für mich? :)

Ich habe versucht mal die Angaben aus der Support-Datei zu ziehen, event. kannst du sie ja interpretieren:

Code:
qdisc pfifo_fast 0: dev acc0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 42394 bytes 473 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev vlan_master0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 686415801 bytes 697732 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc tbf 2: dev eth0 root refcnt 2 rate 98999Kbit burst 319977b lat 640us 
 Sent 192810305 bytes 280108 pkt (dropped 6655, overlimits 191136 requeues 0) 
 backlog 0b 96p requeues 0 
qdisc llq 10: dev eth0 parent 2: minq 1 maxq 255 default 6
 Sent 202168832 bytes 286460 pkt (dropped 6256, overlimits 399 requeues 0) 
 backlog 0b 96p requeues 0 
qdisc sfq 104: dev eth0 parent 10:4 limit 32p quantum 100b perturb 10sec 
 Sent 10573697 bytes 20990 pkt (dropped 429, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 105: dev eth0 parent 10:5 limit 32p quantum 100b perturb 10sec 
 Sent 8299099 bytes 138475 pkt (dropped 16, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 106: dev eth0 parent 10:6 limit 32p quantum 100b perturb 10sec 
 Sent 173806308 bytes 119753 pkt (dropped 6306, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 107: dev eth0 parent 10:7 limit 32p quantum 100b perturb 10sec 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev adsl 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) 
 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 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc tbf 2: dev acc0.4 root refcnt 2 rate 1013Kbit burst 3275b lat 639us 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc llq 10: dev acc0.4 parent 2: minq 1 maxq 255 default 6
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 104: dev acc0.4 parent 10:4 limit 32p quantum 100b perturb 10sec 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 105: dev acc0.4 parent 10:5 limit 32p quantum 100b perturb 10sec 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 106: dev acc0.4 parent 10:6 limit 32p quantum 100b perturb 10sec 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 107: dev acc0.4 parent 10:7 limit 32p quantum 100b perturb 10sec 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc pfifo_fast 0: dev wifi1 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) 
 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 773264 bytes 7909 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0

Was halt klar zu sehen ist, ist beim Config Export die Werte der Config-Variable:

Code:
 speed_in_netto = 200000;
speed_out_netto = 99999;

Diesen Wert habe ich immer in der Config selbst wenn ich die Config manuell ändere, die Prüfsumme anpasse und die Config wieder hochlade, erneuter Export bringt wieder diesen max. 100Mbit Wert. Ich denke hier ist irgendwo ein hardcoded Limit das fälschlicherweise im LAN1 Betrieb greift.
Eine 7590 vom Nachbarn hat dieses Phänomen übrigens nicht, ich vermute daher das das eine "Eigenart" der Kabelboxen ist.

Dan
 
qdisc tbf 2: dev eth0 root refcnt 2 rate 98999Kbit burst 319977b lat 640us

Ich gehe davon aus dass das der Knackpunkt ist. Damit ist der upload nach eth0 (= LAN1) auf 100MBit limitiert.

Wenn AVM keine Moeglichkeit liefert das per Konfiguration zu aendern dann hilft wohl tatsaechlich nur noch eigenhaendig per tc Kommando modifizieren, falls Du das auf dich nehmen willst (und es keine Mietbox ist). Fuer einen login entweder den 6490 freetz branch von @f666 installieren, oder meine Modifikation.
Was die Installation betrifft gibt es ein hervorragendes HowTo von @qwertz-asdfgh : /howto-aendern-des-branding-und-installieren-der-retail-firmware-bei-fritz-box-cable-160
 
Zuletzt bearbeitet:
Besten Dank für dein Feedback, ich bin mittlerweile nochmal per e-Mail an den Support heran getreten und dort wohl auf offenere Ohren gestoßen.
Leider scheint momentan mehr das Gerät vor der Fritzbox (NT vom ISP) sowie meiner Artikel und Seriennummer interessant zu sein, aber ich habe noch Hoffnung das AVM das Problem doch erkennt, eigentlich sollte die Sache ja relativ klar sein nur das warum wäre noch interessant bzw. wie es gelöst werden kann.

Zum Thema Eigenhilfe:

Ich habe gerade mal deinen Branch ausgecheckt und gegen die 06.87 Firmware laufen lassen, erhalten habe ich jetzt ein TAR womit ich ja recht wenig ohne Telnet anfangen kann. Gehe ich recht das ich für die von dir verlinkte Anleitung die .image Dateien aus dem x86 und arm Verzeichnis nehmen kann?

Ich würde also nur die beiden Images per ADAM flashen und das war's?

Dan
 
Ja, das releaseXX/fb6490_YY-XX.tar wieder auspacken (ist vom Aufbau identisch zum original .image) und die einzelnen images (2x kernel, 2x filesystem) gemaess HowTo via ADAM flashen.
 
  • Like
Reaktionen: karl001
Das lief doch mal wie am Schnürchen! :)

2 Fragen vielleicht noch:

1. Weißt du wieso nvsync diesen Fehler raus schmeisst:

Code:
# nvsync
WARNING: can't open config file: /etc/ssl/openssl.cnf
unable to write 'random state'
WARNING: can't open config file: /etc/ssl/openssl.cnf
Error Reading Output File
3078461076:error:02001002:system library:fopen:No such file or directory:bss_file.c:166:fopen('/var/media/ftp/ffritz/data/key.enc','wb')
3078461076:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:169:

2. Hast du vielleicht den Syntax für das TC Änderungskommando "parat"? Ansonsten muss ich mal schauen wo ich das herbekomme...

Auf jeden Fall schon mal herzlichen Dank für deine Hilfe!

Dan
 
ups. Das mit dem openssl.cnf ist "normal" bzw. kein Problem, der Rest nicht. Ich glaube da fehlt ein directory, probier mal

mkdir -p /var/media/ftp/ffritz/data
nvsync

Nein, tc syntax habe ich nicht im kopf, ist schon wieder eine Weile her. man tc :)
 
Sieht gut aus! :)

Code:
# mkdir -p /var/media/ftp/ffritz/data
# nvsync
WARNING: can't open config file: /etc/ssl/openssl.cnf
unable to write 'random state'
WARNING: can't open config file: /etc/ssl/openssl.cnf
WARNING: can't open config file: /etc/ssl/openssl.cnf
+++ Success

Der Vollständigkeit halber, den TC Befehl habe ich jetzt wie folgt:

Code:
/sbin/tc qdisc change dev eth0 root tbf rate 198000Kbit burst 3168b lat 100.0ms

Damit ist der Upstream jetzt bis ca. 186Mbit nutzbar, höhere Werte ergeben Einbrüche... Damit ist mein Problem erstmal vom Tisch, nochmal vielen Dank für die Hilfe!

Grundsätzlich würde mich jetzt nur noch interessieren wo die Regeln OS-seitig gebaut werden, ein Edit der ar7.conf war schon mal ohne Erfolg, die Regeln werden trotzdem nicht angepasst.
Notfalls müsste man den TC Befehl irgendwo persistent machen, geht das einfach über die rc.S?
 
Zuletzt bearbeitet:
Fuer den kabel betrieb wird das ja dynamisch je nach gebuchter upload rate gemacht um buffer bloat zu verhindern. Auserdem kann man ja zur laufzeit die modi aendern, wenn ich mich nicht taeusche.
Es reicht also denke ich nicht es in einem rc script zu machen.

Wenn du es probieren willst, einfach eines in atom/mod/etc/init.d schreiben (oder usr/local/etc/init.d/rc.user, was vonetc/init.d/S97ffusr gestartet wird), das wird dann beim bauen in das modifizierte image gemergt.
Als hack kannst du ja einen hintergrundprozess starten der alle Minute mal schaut ob es noch stimmt und dann "richtig" stellt :)

Wie hoch ist eigentlich die CPU last bei so viel traffic?
 
OK, fröhliche Image Bastelei also... ;) Die CPU juckt den Traffic nicht die Bohne, es gibt bei voller Auslastung nicht mal einen Peak >1% , bei reinem LAN Traffic wundert mich das auch nicht, die schiebt er ja eigentlich nur durch, DPI o.ä. macht die Box nicht für den Rest dürfte sie offloading können...

Ich habe mich allerdings bisher nur auf dem Atom Core aufgehalten, da hier das QoS greift sollte der ja zuständig sein.

BTW: QoS ändert sich nicht, der Wert den ich eingestellt habe ist bis jetzt weiter so vorhanden, ich denke nicht das da dynamisch was geändert wird, zumindest im LAN1 Betrieb...
 
Hat jemand zufällig eine Idee welcher Prozess die TC Commands baut? Fakt ist bei jedem Internet "Reconnect" werden alle QoS Regeln neu gesetzt, ich finde allerdings nichts in Textform also Script im Dateisystem...

AVM schickt mich übrigens weiter in die Wüste, selbst nach allen Informationen wollen sie jetzt Speedtests ohne Geräte an der Box etc. also ob das irgendwelche Auswirkungen hätte...
Ich weiß echt nicht mehr was ich denen noch erzählen soll nachdem ich denen schon die passende TC Zeile aus ihrer Support.txt gepasted habe... :(
 
Das dürfte alles unter dem Stichwort "nqos" laufen und wenn man mal ein "grep" dafür über die entpackte Firmware laufen läßt, wird man auch schnell fündig (sowohl in Strings in Modulen (Libs, Binaries) als auch in Funktionsnamen ... der "kdsldmod.ko" bei der 6490 ist ja -zumindest in der 06.87- seitens AVM "unstripped", ob absichtlich oder irrtümlich, will ich nicht beurteilen).

Da die "Queueing Disciplines" ja die logische Fortsetzung nach der Klassifizierung des Traffics sind (siehe "cat /proc/kdsld/nqos/*"), dürften die auch von derselben Komponente verwaltet werden, wobei das mit dem "(k)dsld" bei AVM eher ein Konglomerat aus mehreren Komponenten mit unterschiedlichen Aufgaben ist, als ein ganz gezielter, gekapselter Prozess (auch wenn es den "dsld" natürlich gibt).

Da ist u.a. der gesamte WAN-IP-Stack von AVM enthalten und man kann (vermutlich bzw. nach meiner Ansicht) mit Fug und Recht behaupten, daß "kdsldmod.ko", "dsld", "multid", "dnsd", "ddnsd" und "voipd" fast eine Einheit bilden und so eng aufeinander abgestimmt sind, daß man da nichts wirklich einzeln herauslösen oder "umleiten" kann - vielleicht noch mit Ausnahme von DNS und SIP.

Wer also ein Problem wie hier lösen will, sollte sich am ehesten einen eigenen Prozess basteln (Shell reicht ja vollkommen), mit dem dann per Polling (oder man läßt sich im "onlinechanged" benachrichtigen) der TBF-Eintrag entsprechend modifiziert wird, wenn es erforderlich sein sollte, weil zwischenzeitlich ein Reconnect erfolgte.
 
Wer also ein Problem wie hier lösen will, sollte sich am ehesten einen eigenen Prozess basteln (Shell reicht ja vollkommen), mit dem dann per Polling (oder man läßt sich im "onlinechanged" benachrichtigen) der TBF-Eintrag entsprechend modifiziert wird, wenn es erforderlich sein sollte, weil zwischenzeitlich ein Reconnect erfolgte.

Danke für deine Ausführungen PeterPawn.
Onlinechanged sieht extrem gut aus als Ansatzpunkt, ich Frage mich nur ob er auch aufgerufen wird im LAN1 Betrieb, laut Freetz Wiki bleibt er stumm bei "Mitbenutzungsbetrieb" und genau diesen Mist zeigt die 6490 in der WebGUI an wenn ich auf LAN1 Betrieb umgeschaltet habe.
 
Ich glaube man findet den string fuer den tc Aufruf in der Tat im dsld.

Falls tc tatsaechlich ueber system() aufgerufen wird, was man mittels strace -p `pidof dsld` pruefen kann (evtl. auch ltrace), koennte man ja /sbin/tc durch einen shell wrapper ersetzten der eine Aenderung fuer eth0 einfach blockiert bzw. den eigenen Wuenschen entsprechend abaendert.
 
Success! ;-)

Irgendwie ist das alles schon viel zu einfach, danke fesc & PeterPawn für eure tolle Vorarbeit und Tips!

Ich habe unter /etc/onlinechanged einfach ein weiteres Script hinzugefügt:

Code:
#!/bin/sh

TC=/sbin/tc

echo qos_altering "$1" "$2"

case "$1" in

online )
                test -x $TC && $TC qdisc change dev eth0 root tbf rate 198000Kbit burst 3168b lat 100.0ms 
                ;;

onlineipv6 )
                test -x $TC && $TC qdisc change dev eth0 root tbf rate 198000Kbit burst 3168b lat 100.0ms
                ;;

esac

Extrem rudimentär aber es funktioniert, beim hochfahren hat die Box schön brav die richtige Rate gesetzt....
 
"Mitbenutzungsbetrieb"
Bist Du sicher, dass der "Mitbenutzungsbetrieb", aka Betriebsart "IP-Client" bei einer FB6490 möglich ist ?
Lösungsvorschläge werden gerne genommen;
der Routerbetrieb (mit NATing) via LAN1 Port ist mir bekannt.
 
Bist Du sicher, dass der "Mitbenutzungsbetrieb", aka Betriebsart "IP-Client" bei einer FB6490 möglich ist ?

Leider nein, die Betextung in der GUI finde ich auch etwas irreführend. Meine Box beherrscht einzig den LAN1 Betrieb, dort steht dann:

Code:
IPv6, verbunden seit 15.03.2018, 17:10 Uhr

IPv6-Adresse: xxx

FRITZ!Box benutzt eine direkte IP-Verbindung zu einem Internetanbieter

Meine 7312 unterstützt diesen Client Modus, dort steht dann:

Code:
IPv6, Eine bestehende Internetverbindung im Netzwerk wird mitbenutzt.

IPv6-Adresse: xxx
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.