Diverses: 6490, 6590, Puma6-Probleme bei anderen Herstellern, Puma7-Design

@robert_s : Wobei deine "idle ping" latenz natuerlich schon extrem schlecht ist, was ist denn da los?
Keine Ahnung, was da los war. Heute bekam ich auch ein einwandfreies "Idle"-Resultat:

http://www.dslreports.com/speedtest/14858783

- - - Aktualisiert - - -

Ich hänge mit einer 6490 (06.63) an einem Arris-CMTS (100er-Vertrag bei VF/KDG, 20/4 Kanäle provisioniert) und erziele dieses Ergebnis: http://www.dslreports.com/speedtest/14834874 (06.05.2017, 01:04 Uhr)
[...]
beim Download macht sich ja praktisch gar kein Bufferbloat bemerkbar bei mir.
Was aber auch daran liegen kann, dass der "Flaschenhals" vielleicht gar nicht am CMTS liegt, sondern woanders auf der Strecke: Bei VFKD kommt normalerweise netto etwas mehr als die beworbene Bitrate heraus. Hast Du vielleicht die LAN-Verbindung nur im Fast Ethernet Modus?
 
Nein, ist eine GbE-Verbindung ... ein Test um diese Uhrzeit kommt auch über die "magischen" 100 MBit/s hinaus und hier zeigt sich dann auch tatsächlich ein Bufferbloat-"Problem" - das würde ich aber auf die Auslastung des Segments zurückführen, die am Samstagabend sicherlich höher ist als nachts um 1 Uhr - wobei man hier vielleicht auch zwischen der Auslastung durch mehrere CM und der "Dauerbelegung" durch einzelne unterscheiden muß?

Bei mehreren CM mit einem "Verbindungswunsch" greift natürlich für jedes von ihnen nur die individuelle Drosselung auf die vertraglich vereinbarte Bandbreite (was in der Summe sicherlich mehr Bedarf beim CMTS ergibt) und das kann eine andere (temporäre, maximale) Auslastung der Kanäle fürs Bonding erzeugen, als ein paar Dauersauger, die ihrerseits ja auch jeweils gedrosselt werden, aber eben für ein "Grundrauschen" sorgen.

Jedenfalls korreliert dieses Ergebnis von heute abend auch mit meinen eigenen Beobachtungen, daß (vielleicht merkwürdigerweise, wenn man anderen KDG-Kunden zuhört) bei mir die Latenzen nach 22 Uhr wieder sinken, leider aber genauso auch der Durchsatz (zum Glück nur um ca. 10 Prozent), der wieder zuvor zwischen 18 und 22 Uhr kaum einbricht im Vergleich zu den Stunden davor.

Bisher erkläre ich mir das eben mit einer höheren "Konkurrenz" zwischen 18 und 22 Uhr, wobei eben auch da bei mir ein "gemittelter Durchsatz" erreicht wird, der dem Vertrag entspricht. Vermutlich gibt es zwar viele parallele Datenübertragungen im Segment, aber nur mit geringeren Datenmengen und das ändert sich wohl in der Nacht, wo dann die höheren Datenmengen dauerhaft (oder zumindest langfristiger) übertragen werden und wo sich die Situation dann gegen 4 Uhr wieder "entspannt".

Mein Test vorhin: http://www.dslreports.com/speedtest/14875781
 
Was aber auch daran liegen kann, dass der "Flaschenhals" vielleicht gar nicht am CMTS liegt, sondern woanders auf der Strecke:

Man kann das CMTS (zumindest vermute ich das) vom arm core direkt anpingen. Die latenz ist genauso hoch wie die bei dslreports angezeige während ein test läuft.
Damit kann man ganz gut ausschließen/feststellen dass/ob der bufferbloat uirgendwo anders auf der strecke erzeugt wird.
Die Adresse bekommt man einfach mit "/sbin/arp -n|grep wan0".
 
Offenbar darf man den Einfluss von Betriebssystem, Browser und Testeinstellungen nicht unterschätzen.

In Windows 10 mit dem Edge-Browser bricht der Test mit den Standardeinstellungen ab und muss auf "Staged POST" als Upload-Methode umgestellt werden. Dann habe ich diese Testreihe durchgeführt:

Ubuntu 16.04.2 LTS (64-bit) mit Firefox 53.0:

http://www.dslreports.com/speedtest/14902223

-> Idle und Uploading gut, Bufferbloat beim Downstream-Test, Bufferbloat-Note C

Windows 10 Pro (64-bit) mit eingebauten Edge-Browser (auf demselben PC), innerhalb von wenigen Minuten nach obigem Test:

https://www.dslreports.com/speedtest/14902397

-> Alle Tests gut, Bufferbloat-Note A

Wieder zurück zu Ubuntu 16.04.2 LTS (64-bit) mit Firefox 53.0:

http://www.dslreports.com/speedtest/14902841

-> Wieder die gleichen Ergebnisse wie anfangs mit Ubuntu, Bufferbloat-Note C

Und wenn ich in Ubuntu den Upstream-Testmodus wieder von "Staged POST" auf den Default zurückstelle:

http://www.dslreports.com/speedtest/14902876

Man sieht an den Graphen recht deutlich, dass da unterschiedliche "Congestion Control" Strategien verwendet werden: Ubuntu/Linux verwendet beim Download offenbar eine recht "aggressive", die schnell die maximale Bitrate erreicht, dafür aber auch den Downstream-Puffer im CMTS anschwellen lässt - während Windows 10 wohl eine "vorsichtigere" Strategie verwendet, welche deutlich langsamer zum Maximum führt, dafür aber den CMTS-Puffer nicht überfüllt.

Und im Upstream sieht man auch, dass der Standardmodus anfangs über das Bitratenlimit hinaus schnellt und dann sehr unregelmäßig läuft, während "Staged POST" das nicht tut und sehr "glatte" Ergebnisse liefert.

Also ist es gar nicht so einfach, "Bufferbloat" zuverlässig zu detektieren. Denn wenn tatsächlich auch der Browser und der Testmodus einen Einfluss haben, kann es sein, dass einem der dslreports-Test ein "A" beschert, man bei tatsächlichen Download- oder Upload-Anwendungen, welche den TCP/IP-Stack vielleicht anders verwenden, dann doch wieder Bufferbloat hat...
 
Zuletzt bearbeitet:
http://www.dslreports.com/speedtest/14910832

Test mit der 6590 bei mir. Windows 10, keine Probleme.

14910832.png
 
Das ist interessant, denn im Primacom-Forum gibt es jemanden, der auch mit der 6.83-44269 FW und am Cisco-CMTS ähnliche Ergebnisse wie Du bekommt - während jemand anderes einwandfreie Ergebnisse erhält.

Das Problem im Primacom Forum lag anscheinend an einem Tool CFOSSPEED aber kenne mich mit Windows nicht aus wofür das gut sein soll. Nachdem dieses deinstalliert war ging der Test auch mit A durch.
Der Test mit Ubuntu war dafür hilfreich um dem noch auf die Schliche zu kommen.
 
Mit firmware 6.83 ist (zumindest mein) Problem definitv behoben. dslreports meldet ueberall note A, keine relevante Verschlechterung der RTT.
 
Wobei mir jetzt auch klarer wird was geändert wurde: Das komplette routing läuft jetzt über den atom core, upstream traffic via eth_udma0 (einer der UDMA ports des internen l2 switch).
Dafür sind (im Gegensatz zu 6.6x) jetzt auch entsprechende qdisc rules vorhanden:
Code:
# /sbin/tc  qdisc show
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
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
qdisc tbf 2: dev eth_udma0 root refcnt 2 rate 3960Kbit burst 12799b lat 640us
qdisc llq 10: dev eth_udma0 parent 2: minq 1 maxq 255 default 6
qdisc sfq 104: dev eth_udma0 parent 10:4 limit 32p quantum 100b perturb 10sec
qdisc sfq 105: dev eth_udma0 parent 10:5 limit 32p quantum 100b perturb 10sec
qdisc sfq 106: dev eth_udma0 parent 10:6 limit 32p quantum 100b perturb 10sec
qdisc sfq 107: dev eth_udma0 parent 10:7 limit 32p quantum 100b perturb 10sec
qdisc pfifo_fast 0: dev eth_udma1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
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
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
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
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
qdisc pfifo_fast 0: dev tap0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 
Ich würde ja sagen, daß die nqos-Queues auch nur auf den ATOM-Core umgezogen sind (dabei haben sich dann halt auch Interface-Namen geändert) ... die gab es vorher halt auf dem ARM-Core, aber im Prinzip mit demselben Aufbau -> unten ein TBF, darauf der LLQ von AVM mit seinen Queues und dann noch auf ein paar dieser Queues ein SFQ, damit über verschiedene Verbindungen "gerecht" verteilt werden kann.
 
Aber der lan->wan traffic ging vorher nicht ueber den arm core.
 
[Compal CH7465LG-LC]

Hallo,

konnte vor ein paar Tagen über die Bucht "günstig" eine sogenannte UPC Connect Box erwerben, erhalten habe ich das Modell CH7465LG-LC der FIrma Compal. Grund war mein Wunsch ein Gerät im Bestand zu haben was den sogenannten Bridge Mode beherscht, um dies z.B. bei Bedarf mit einer 7590 am Kabel Anschluss zu kombinieren.

Nach einem Komplett Reset konnte ich den Bridge Mode aktiveren und das Gerät bei "Vodafone Kabel" erfolgreich als Zugangsgerät aktivieren.

Leider musste ich festellen das dieser Geräte Typ einen Puma 6 Chipsatz von Intel nutzt und hier der Latenz BUG voll zur Geltung kommt. Der Test auf der Seite dslreports.com zeige hier ein ganz klares Fehlerbild, also leider nur als Notfall Gerät nutzbar wenn das Vodafone Gerät mal ausfällt und der Kunde ein Bridge Mode Gerät benötigt.
 
[Compal CH7465LG-LC]

Leider musste ich festellen das dieser Geräte Typ einen Puma 6 Chipsatz von Intel nutzt und hier der Latenz BUG voll zur Geltung kommt.
Welche Firmwareversion ist denn auf dem Gerät drauf?

Für das "Schwestergerät", den CH7466CE, gab es unlängst bei VFKD ein Firmwareupdate auf Version 4.50.19.12. Wenn das hier das "Modifikationen" Unterforum wäre, könnte man ja mal andenken, ob man an die rankommt, und ob man damit und einem CH7465LG etwas anfangen kann...

Wofür mögen eigentlich die letzten beiden Buchstaben der Modellbezeichnung stehen...?
 
Hallo,

sorry hat etwas länger gedauert, hier die entsprechende Firmware Version:

fimrware.jpg

Was die Bezeichnung angeht habe ich auch keine Idee.

greetz
Enno
 
Zuletzt bearbeitet:
Hier wollen sie jitter und packet loss mit iperf3
https://iperf.fr/iperf-download.php#windows
messen:

https://www.unitymediaforum.de/viewtopic.php?p=382229#p382229
UM connect box und ansonsten fritz 63/6490.
Mit der 6590 / 6.84 sehe ich den Packet Loss, aber nicht den Jitter:

$ iperf3 -c ping.online.net -u -p 5209 -P 10
[...]
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 4.187 ms 58/158 (37%)
[ 4] Sent 158 datagrams
[ 6] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 4.039 ms 58/158 (37%)
[ 6] Sent 158 datagrams
[ 8] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 4.097 ms 58/158 (37%)
[ 8] Sent 158 datagrams
[ 10] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 4.239 ms 58/158 (37%)
[ 10] Sent 158 datagrams
[ 12] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 4.136 ms 58/158 (37%)
[ 12] Sent 158 datagrams
[ 14] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 3.833 ms 68/159 (43%)
[ 14] Sent 159 datagrams
[ 16] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 4.631 ms 72/159 (45%)
[ 16] Sent 159 datagrams
[ 18] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 6.578 ms 68/159 (43%)
[ 18] Sent 159 datagrams
[ 20] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 7.500 ms 75/159 (47%)
[ 20] Sent 159 datagrams
[ 22] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 7.200 ms 65/159 (41%)
[ 22] Sent 159 datagrams
[SUM] 0.00-10.00 sec 12.4 MBytes 10.4 Mbits/sec 5.044 ms 638/1585 (40%)

Mit bis zu 4 parallelen Streams geht es auch ohne Verluste:

$ iperf3 -c ping.online.net -u -p 5209 -P 4
[...]
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 6.033 ms 0/159 (0%)
[ 4] Sent 159 datagrams
[ 6] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 6.423 ms 0/159 (0%)
[ 6] Sent 159 datagrams
[ 8] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 7.315 ms 0/159 (0%)
[ 8] Sent 159 datagrams
[ 10] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 6.878 ms 0/159 (0%)
[ 10] Sent 159 datagrams
[SUM] 0.00-10.00 sec 4.97 MBytes 4.17 Mbits/sec 6.662 ms 0/636 (0%)

Und den puma6fail DOS exploit konntense auch reproduzieren:
https://www.unitymediaforum.de/viewtopic.php?p=382383#p382383
Das PHP-Script legt allerdings auch meine 6590 lahm: Wenn es läuft, komme ich nicht mehr auf die Weboberfläche der Fritz!Box, und UPNP-Abfragen gehen auch nicht mehr. Nach dem Beenden geht es aber wieder.

Stecken denn andere Router es weg, wenn man da im 75µs-Takt UDP-Pakete an Zufallsports durchjagt?
 
https://www.intel.com/content/www/us/en/connected-home/ibc-smarthome-gateway-tech-brief.html

Customizable distribution based on the 3.x Linux Kernel provides a stable, open source supported development environment
Entweder Intel lügt hier schamlos in einem (Marketing-)Paper oder es gibt die Patches von Intel doch für verschiedene Kernel-Versionen. AVM verwendet hier ja einen 2.6.39(.3)-Kernel.

Interessant ist auch die Feststellung
Built-in hardware virtualization with Intel® Virtualization Technology (Intel® VT) and local storage makes it easy for service providers to add new revenue streams through additional IoT services such as home automation, home security, or energy management solutions. And because these services are added through a virtual machine, they can be dropped in on the fly, isolated from each other, and if a problem occurs, you only need to restart that VM and not the entire gateway.
Das klingt irgendwie so, als könnte auch der Puma6 bereits (vermutlich aber nur auf dem ATOM-Core) mit VMs umgehen. Beim GRX350 (in den 75x0-Modellen - und nein, die 7570 ist da ausdrücklich nicht eingeschlossen, es gilt also "x != 7") ist das ja vermutlich auch der Fall, wie die zwei Kernel in der Image-Datei vermuten lassen (da läuft wohl das komplette FRITZ!OS von AVM in so einer virtuellen Maschine und es gibt auch nur die eine zur Zeit - ist aber auch alles nur "Schlußfolgerung" anhand von bestimmten Anzeichen und kein gesichertes Wissen).

----------------------

Ansonsten habe ich den Hintergrund für den DoS-Angriff auf Puma6-Geräte damals so verstanden (muß nicht stimmen, was ich da hineininterpretiere), daß dabei durch viele (UDP-)Pakete (praktisch ohne nennenswerten Payload) auf dem Cable-Modem (also noch vor der Software-Firewall von AVM, wo das Modem selbst noch gar nicht weiß, ob die eingehenden Pakete am Ende abgelehnt werden oder nicht) ständig weitere Lookup-Table-Einträge generiert werden (schon auf dem ARM-Core) und daß deren Verwaltung einen derartigen Overhead erzeugt, daß es bis zu einer gewissen Paket-Rate nur wachsende Verzögerungen gibt, aber danach kommt die Hardware dann gar nicht mehr hinterher ... und das ist eben schon mit einem "kleinen" Anschluß für den Angreifer zu bewerkstelligen, weil bereits ein recht niedriger Durchsatz (2-3 Mbps) ausreicht (und das auch mit "unsolicited packets" auf der WAN-Seite), um das Modem nahezu komplett aus dem Spiel zu nehmen.

Das kam ja Ende April 2017 auf (inkl. des Artikels in "The Register")... aber auch das kann kaum der Grund sein, warum AVM die 06.83 für die 6490 dann wieder zurückgezogen hatte. Die 06.63/06.64 verhielt sich dabei m.W. nicht anders und ich dachte eigentlich, daß auch dieses Problem mit der 06.84 (die ich immer noch nicht selbst installiert habe auf der 6490) jetzt vom Tisch wäre ... z.B. weil Intel da die Rate für neue UDP-"Connections" (und ja, ich weiß, daß UDP eigentlich verbindungslos arbeitet) limitiert. Das geht zwar nur für alle UDP-Pakete gleichzeitig (weil man deren Absenderadresse zu leicht fälschen kann, hilft es hier auch nicht wirklich, wenn man das nur pro Absenderadresse limitiert), aber als "real world scenario" gibt es eigentlich keinen Anwendungsfall (oder ich kenne einen solchen nur nicht), wo > 2.000 UDP-Pakete pro Sekunde mit wechselnden Adressen und Ports verwendet würden ... und die wechselnde Portnummer ist hier ja nach meinem Verständnis entscheidend, weil sonst kein neuer LUT-Eintrag erzeugt werden muß.

Wobei ich den Test hier (https://www.unitymediaforum.de/viewtopic.php?p=382383#p382383) nicht nachvollziehen kann ... da wird dann dieser Traffic zur Adresse des Google-DNS erzeugt (also offensichtlich "von innen")? Das ist nicht das eigentliche DoS-Problem, was Ende April für den Puma6-Prozessor beschrieben wurde (da ging es um "unsolicited traffic" von außen, den man auch nicht blockieren kann bzw. wo die Firewall im eRouter dann zu spät dran ist, um den Overload zu verhindern) und wenn Du das ebenso getestet hast, ist es auch weniger verwunderlich, wenn das in der 06.84 noch vorhanden wäre.

Bei ausgehenden Verbindungen wird ja tatsächlich auch für die gesamte Dauer dieser "Verbindung" (wie lang bei AVM das UDP-Timeout ist, weiß ich gerade nicht und ich habe auch keine Lust, jetzt nachzuschauen - sollte sich über /proc/net/avm_pa/sessions leicht ermitteln lassen) ein Eintrag benötigt, damit das "connection tracking" funktioniert. Da dürfte von innen sogar noch viel schneller das Ende der Fahnenstange erreicht sein, was die max. Anzahl der PA-Sessions angeht. Die maximale Anzahl bei der 6490 waren da (iirc) 255 Sitzungen - ich weiß aber auch nicht mehr, wie sich das System da bei "overload" verhält und ob es diese "Sitzungen" nicht doch noch versucht zu starten und sie dafür in einer Warteschlange verwaltet.

Wobei ich auch hier wieder nicht verstehe, warum das die Verfügbarkeit des GUI und/oder anderer Dienste auf der Box selbst in Richtung LAN beeinflussen sollte ... die dürften gar nichts mit dem PA zu tun haben und - zumindest dort - auch nicht mit limitierten Ressourcen. Hier könnte aber auf der anderen Seite dann wieder das verwendete System eine Rolle spielen ... einerseits kann das System, auf dem das PHP-Skript läuft, an die Grenzen seiner Ressourcen kommen (auch eine Firewall, die hier ggf. läuft, muß da ja CT machen) oder es gibt wirklich am Ende ein Ressourcen-Problem auf der Box. Aber das können kaum TCP-Handle o.ä. sein (damit das GUI "unresponsive" wird oder auch TR-064) ... denn der gesamte Transit-Traffic dürfte auf dem TCP-Stack der Box selbst keine "Verbindungen" erzeugen und ein Overload des Prozessors kann ich mir mit 5.000 pps auch nicht so richtig vorstellen ... höchstens noch ein Deadlock irgendwo im IP-Stack, wenn auf freie PA-Sessions gewartet werden sollte oder auch eine Priorisierung von Transit ggü. lokalen Requests.

Der "DoS-Test" mit ausgehenden Verbindungen bringt also nichts ... das muß schon von außen an die eigene öffentliche IP-Adresse gesendet werden. Von innen sollte man mit einem ähnlichen Szenario tatsächlich so ziemlich jeden beliebigen Router in die Bredouille bringen können ... spätestens dann, wenn ihm die Portnummern (auf der WAN-Seite) für das NAT ausgehen.

Ob der dann gleich die Pakete verwirft (ggf. mit passender ICMP-Nachricht an den Absender) oder die Requests irgendwo "queued" in der Hoffnung, daß es innerhalb der Timeout-Zeit des Absenders noch freie Ressourcen geben könnte um eine neue Session zu kreieren, wird vermutlich von verschiedenen Herstellern auch unterschiedlich gehandhabt. Wobei "netfilter" (sicherlich von den meisten Nicht-AVM-Geräten verwendet für die Router-Firewall) meines Wissens beim Erreichen des Wertes in "net.ipv4.netfilter.ip_conntrack_max" dann einfach droppt und das entsprechend protokolliert (ip_conntrack: table full, dropping packet.).
 
Danke PeterPawn, ich habs oben angemerkt. Wird iperf3 hier richtig eingesetzt für den puma6 latency/jitter bug?
 
ftp://download.avm.de/fritz.box/fritzbox_6490_cable/firmware/deutsch/info.txt

Produkt: FRITZ!Box 6490 Cable
Version: FRITZ!OS 6.84
Sprache: deutsch
Release-Datum: 07.09.2017

Neue Features: - ab 6.84: Aktueller Modemtreiber implementiert
- Ein Plus an Sicherheit und Netzanpassungen

Das könnte doch ein Puma update sein?

Einige Tests hier bestätigen das:
https://www.unitymediaforum.de/viewtopic.php?f=53&t=35824
 
http://badmodems.com/Security.htm

Intel Product Security has acknowledged the issue and agreed to a security rating of HIGH but has not issued a CVE or alert on the issue, the CVE that Intel said would be assigned to this is CVE-2017-5693 -here-

Das ist der letzte Stand. Alle warten auf das CVE und einen Firmware fix.
 
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.