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

[Cataclysm_177]

Warum eigentlich jetzt Plötzlich auch Puma7?

 

[woprr]

Das musste hier nachlesen:
https://www.dslreports.com/forum/r31122204-SB6190-Puma6-TCP-UDP-Network-Latency-Issue-Discussion

...

Also wenn sich da weiter nix tut gegen den Pumageddon DoS dann setzt es Anzeigen:
https://www.gesetze-im-internet.de/bsig_2009/__14.html

 

[woprr]

So, BSI und CERT sind eingeschaltet, mir reichts jetzt. UM antwortet "...keine Informationen..."

"0-day DoS with public exploit without mitigation", zack, zack!

Diese Bugs sind von Intel längst öffentlich bestätigte Tatsachen, steht alles hier http://badmodems.com/

 

[mr999]

Moin,

ich habe von meinem Provider RFT Kabel einen neuen cable Router bekommen.
Es handelt sich hierbei um den Arris TG2492:
http://de.arris.com/produkte/touchstone-telefonie-gateway-tg2492-s-155i5/

Dieser hat wohl auch den Puma 6 Chipsatz.

Folgendes Problem habe ich damit.
Wenn ich nur den Router anpinge, ich nutze dafür http://winmtr.net/download-winmtr, ist der Ping nicht bei 1ms wie es sein sollte, sondern meistens bei 3-6 ms.

Manchmal gibt es einen Ping Spike auf 75ms hoch:
|------------------------------------------------------------------------------------------|

| WinMTR statistics |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

| 192.168.0.1 - 0 | 153 | 153 | 1 | 4 | 75 | 50 |

|________________________________________________|______|______|______|______|______|______|


Der PC ist ist direkt mit dem Router mit einem kurzen LAN Kabel angeschlossen. Ich habe auch andere Kabel getestet.
Ich habe alle 4 Gigabit LAN Ports ausprobiert. Und es findet kein weiterer Netzwerktraffic statt.

Das 2. Problem ist, wenn ich einen upload durchführe, z.B. über https://testmy.net/upload, und zeitgleich dabei einen Pingtest z.B. zu freenet.de durchführe, geht der Ping auf 250 ms hoch.
Teilweise, wenn es einen Ping Spike gibt, bis auf zu 2500 ms:
|------------------------------------------------------------------------------------------|

| WinMTR statistics |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

| 192.168.0.1 - 0 | 28 | 28 | 1 | 4 | 41 | 4 |

| 10.11.95.254 - 0 | 27 | 27 | 10 | 184 | 2540 | 10 |

| 212.37.161.186 - 0 | 27 | 27 | 12 | 184 | 2543 | 14 |

| 212.37.161.175 - 0 | 27 | 27 | 12 | 185 | 2547 | 18 |

| decix.mcbone.net - 5 | 24 | 23 | 29 | 107 | 256 | 34 |

| xe-0-1-1-0.dus2-j.mcbone.net - 5 | 24 | 23 | 31 | 109 | 255 | 33 |

| Vlan52.dus2-x1.mcbone.net - 0 | 27 | 27 | 33 | 211 | 2564 | 35 |

| www.auto.freenet.de - 0 | 27 | 27 | 31 | 211 | 2563 | 35 |

|________________________________________________|______|______|______|______|______|______|


Schliesse ich wieder den alten Cisco EPC3928AD cable Router an, liegt der Ping zum Router bei nur 1 ms.
So wie es sein sollte.

Bei einem Pingtest zu freenet.de und gleichzeitigem Upload ist der Ping nur bei max 100 ms.
Auch wenn ich zu dem Upload noch mit vollen 200 Mbit/s downloade. Also alles ok.

Ich habe das Problem mit 2 PCs und einem Notebook durchgeführt.
Und dabei jeweils die einzelnen PCs per LAN mit den Routern direkt verbunden. Es ist immer wieder reproduzierbar.

Liegt das generell an dem Arris Cable Router, dass der Ping so schlecht ist?
Ist das Problem jemanden bekannt? Oder hat nur dieser Router einen Defekt?
Mit dem Cisco EPC3928AD tritt das Problem ja nicht auf.


Anbei nochmal 4 Ping Tests.

Die beiden oberen sind mit dem Cisco EPC3928AD Router durchgeführt und die beiden unteren mit dem Arris Router:

 

[fesc]

@mr999
#2 sieht nach einem klassischen buffer bloat aus, wie schon eher in diesem thread fuer die 6490 dokumentiert und mit FW 6.83 behoben (indem der gesamte traffic ueber den Atom/Linux kernel mit entsprechenden regeln geroutet wird).
Du kannst mal einen test bei dslreports machen und schauen welchen buffer bloat score Du bekommst.

 

[mr999]

Da zeigt er immer A an. Und bei results angeblich nur Pingschwankungen
von im maximum 147 ms im upload...
http://www.dslreports.com/speedtest/23867740

Obwohl ich nebenbei winmtr laufen lasse und dort viel höhere Pingschwankungen angezeigt werden.
Also irgendwie ist der Test auf DSL Reports überhaupt nicht korrekt.

 

[stoney]

Obwohl ich nebenbei winmtr laufen lasse

Vieleicht liegts aber auch an winmtr oder aus der Kombination herraus - mtr + dsl report

Mal getrennt von einander verglichen ?

 

[mr999]

Ja auch das habe ich.

 

[woprr]

@mr999
#2 sieht nach einem klassischen buffer bloat aus

Konnten die Experten hier nicht bestätigen:
https://www.dslreports.com/forum/r3...sue-Discussion~start=7080?search=buffer+bloat

Ausserdem hat Intel das Latency Problem längst öffentlich eingestanden:
http://badmodems.com/press.htm

 

[mr999]

Und jetzt habe ich wieder den Cisco angeschlossen und bei dem habe ich ja nur sehr niedrige Pingschwankungen. Keine Probleme bei Onlinespielen während eines Uploads.
Nur eben ein bisschen erhöhter Ping. Was ja vollkommen normal ist bei vollem Upload.

DSLreports zeigt im Ergebnis jedoch einen Bufferbloat von C an und Schwankungen von bis zu angeblich 480 ms im upload:
http://www.dslreports.com/speedtest/23930549

Win MTR zeigt jedoch den schlechtesten Ping von nur 141 ms an. Was ziemlich genau ist.

-----------------------------------------------------------------------------------------|

| WinMTR statistics |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

| 192.168.0.1 - 0 | 76 | 76 | 0 | 0 | 1 | 0 |

| 10.11.95.254 - 9 | 57 | 52 | 6 | 29 | 130 | 125 |

| 212.37.161.186 - 9 | 57 | 52 | 7 | 31 | 138 | 130 |

| 212.37.161.175 - 5 | 67 | 64 | 7 | 49 | 146 | 141 |

| 22-160-37-212.ip-pool.rftonline.net - 5 | 65 | 62 | 8 | 46 | 139 | 128 |

| mdlink.bcix.de - 2 | 72 | 71 | 12 | 63 | 144 | 139 |

| gw5-be3-60.core.mdlink.net - 9 | 57 | 52 | 13 | 36 | 139 | 133 |

| gw-asg.core.mdlink.de - 5 | 65 | 62 | 13 | 52 | 144 | 132 |

| www.mdcc-fun.de - 9 | 57 | 52 | 11 | 36 | 141 | 134 |

|________________________________________________|______|______|______|______|______|______|

 

[woprr]

@mr999
mit FW 6.83 behoben (indem der gesamte traffic ueber den Atom/Linux kernel mit entsprechenden regeln geroutet wird).

Das würde nix nützen der traffic muss ja trotzdem über den Puma modemchip ins kabelnetz,

und die Puma Firmware ist closed source, AVM kann da gar nix machen ausser auf Intel warten wie alle anderen auch http://badmodems.com/Fix.htm

 

[fesc]

Lies vielleich noch mal den thread von Anfang an durch (bzw. post #68). Natuerlich kann AVM da was machen (bzw hat gemacht).
Man (ich) konnte den buffer bloat sogar mit der alten AVM firmware verhindern indem ich einen openWRT router davorgeschalten habe (mit den gleichen regeln die jetzt der atom im der FB hat).

Ich bestreite nicht dass der Puma da ein Problem hat, aber er bietet auch ausreichend Resourcen um einen workaround zu implementieren.

 

[woprr]

Ja klar... und den DoS hat AVM dann bestimmt auch gefixt
http://badmodems.com/Security.htm

 

[fesc]

Warum eigentlich so aggresiv? Das eine hat mit dem anderen doch nix zu tun .. mir ging es nur um die Beobachtung dass die RTT bei uplink traffic hoch geht.

 

[robert_s]

Wobei ich schon immer mal wissen wollte, ob jemand hier in D eigentlich eine entsprechende Messung der Latenzen beim Puma6 auch für die AVM-Boxen mal gemacht hat ... die Probleme wurden in den USA ja Anfang Dezember 2016 publik und betrafen mehrere Hersteller mit Puma6-Geräten - inkl. Hitron und Arris (Motorola) und diverse "Rebrands". Dem Vernehmen nach hat Intel dann zusammen mit den Geräteherstellern einen Fix erarbeitet (worin der bestand, habe ich bisher auch noch nicht definitiv(!) finden können) und der wurde dann dort von den KNB auch verteilt.

Ich habe mich dem Thema jetzt mal etwas gewidmet und bin direkt "zur Quelle" im dslreports-Forum gegangen, wo man leider überhaupt nicht froh darüber war, dass ich mit meiner Fritz!Box 6590 Cable mit Firmware 6.85 das Latenz-Problem nicht habe, und auch einen DoS-Angriff (mit 1Mbps 64-Byte UDP-Pakete auf zufällige Portnummern) bis auf einen anfänglichen 5-sekündigen Anstieg der Latenz (>1s, mit Paketverlusten, danach ist die Latenz wieder wie vorher, obwohl der Paketmitschnitt zeigt, dass die Box weiterhin mit UDP-Paketen beschossen wird) unbeschadet überstehe. Da ist man wohl etwas vergnatzt darüber, dass die noch auf die Freigabe der gefixten Firmwares durch ihre ISPs warten, während hier AVM die schon munter an seine Retailkunden verteilt.

Bisher sieht es jedenfalls so aus als hätte AVM den bisher ausgereiftesten Fix von Intel ausgeliefert.

Dass ich bei der Messung (mit PingPlotter Pro) nichts grob falsch mache, konnte ich übrigens mit dem von VFKD gestellten Compal CH7466CE überprüfen, welcher das Latenz-Problem auf Anhieb sehr eindrücklich zeigte. Übrigens selbst mit der aktuellsten von VFKD ausgespielten Firmware 4.50.19.12.

 

[fesc]

Normalerweise koepft man den Ueberbringer schlechter Nachrichten, hier ist es andersherum ..

 

[PeterPawn]

Normalerweise koepft man den Ueberbringer schlechter Nachrichten, hier ist es andersherum ..

Verstehe ich nicht ... wo ist jetzt das Gegenteil zu suchen?

Wird hier nun bei guten Nachrichten geköpft? Wenn ja, was war die gute Nachricht und wer braucht jetzt eine Neuvermessung?

Oder läuft jetzt hier jemand mit zwei Köpfen (und nicht nur zwei Gesichtern) herum? Wer ist das dann und vor allem: "Wächst der auch wieder nach, wie in der Sage?" - ich bin etwas besorgt, zumal einer meiner Server auch noch "hydra" heißt.

 

[BiGOnE]

Ach Peter das ist doch nicht so schwer, robert_s hat etwas positives im dslreports-Forum zur auktuellen Firmware der Fritz!Box 6590 Cable geschrieben, die User dort waren aber überhaupt nicht froh darüber (wollte Ihn köpfen) und wohl auch neidisch das AVM schon einen Fix für die Fehler des Puma Chipsatzes erarbeitet hat.

 

[fesc]

Hallo,

ich habe bzgl. dem UDP DOS etwas experiementiert, und (wie @robert_s) festgestellt dass sich die 6.85 wesentlich (!) besser verhält aus 6.83. Bei einem Angriff geht kurz die Latenz hoch, aber nichts dramatisches, i.A. kein packet loss. Bei 6.83 bricht alles über die Dauer des Angriffs ein.

Wenn ich mir das auf dem arm core mit tcpdump ansehe stelle ich fest dass alle Pakete des Angreifers mit "original" source/destination auf dem erouter0 interface ankommen (und zwar in rx-richtung). Nach ca. 2-3 Sekunden wird der UDP strom "gekappt". Das ist wohl der fix/workaround. TCP und ICMP zum Angreifer bleiben stabil (wobei der Angriff angeblich auch mit TCP gehen soll ..).

@PeterPawn, vielleicht weisst Du (oder jemand anderes) wie man das erouter0 interface zu interpretieren hat (d.h. wo genau sitzt es, und die anderen, "physisch"). Da die downlink pakete im "rx" counter gezählt werden gehe ich davon aus dass erouter0 das interface im eRouter richtung eCM ist (komischerwise ist es bei esafe genau anders herum: DL traffic wird hier als tx gezählt ..).
Ich beziehe mich hier auf das Diagramm auf seite 12 in https://www.scte.org/documents/pdf/Standards/ANSI_SCTE 140 2013.pdf (so das in dieser Form auf den puma6 zutrifft).

Der "fix" (in 6.85) besteht augenscheinlich darin dass der Datenstrom vor dem eigentlichen NAT/Forwarder selektiv gekappt wird (bevor er dort Ärger machen kann). Ob das noch im eRouter passiert oder "davor" weiss ich nicht (aber es fällt mir schwer zu glauben das das eCM dafür genug "Intelligenz" hat).

BG

 

[PeterPawn]

Ich finde die Abbildungen in https://community.cablelabs.com/wik...nload?id=2f4ee74a-3b7f-48e4-a72f-f78145487c0a aussagekräftiger.

Ansonsten kann ich mir problemlos vorstellen, daß Intel da auch auf der CPE-Seite des eCM eine Limitierung der UDP-Pakete pro Zeiteinheit hinzugefügt hat - in dem Part, der in Abbildung 5-16 als "MAC Bridge and Filters" bezeichnet ist bzw. genauer gesagt, direkt davor. Denn das dürfte die Stelle sein, die durch zuviele neue UDP-"Verbindungen" (oder nennen wir sie vielleicht besser "flows"?) überlastet wurde.

Eine Filterung von Paketen gibt es dort ohnehin bereits (nach Standard schon - docsisDevFilter, über SNMP oder Config-File einstellbar) und da blockiert z.B. VF über einen solchen zusätzlichen Filter alles das, was das Windows-Netzwerk bräuchte (TCP/UDP 137-139 und TCP 135):

SNMP MIB Object(docsDevFilterIpDefault.0):1.3.6.1.2.1.69.1.6.3.0, Integer, 2
SNMP MIB Object(docsDevFilterIpStatus.1):1.3.6.1.2.1.69.1.6.4.1.2.1, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.1):1.3.6.1.2.1.69.1.6.4.1.3.1, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.1):1.3.6.1.2.1.69.1.6.4.1.4.1, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.1):1.3.6.1.2.1.69.1.6.4.1.5.1, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.1):1.3.6.1.2.1.69.1.6.4.1.6.1, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.1):1.3.6.1.2.1.69.1.6.4.1.7.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.1):1.3.6.1.2.1.69.1.6.4.1.8.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.1):1.3.6.1.2.1.69.1.6.4.1.9.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.1):1.3.6.1.2.1.69.1.6.4.1.10.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.1):1.3.6.1.2.1.69.1.6.4.1.11.1, Integer, 6
SNMP MIB Object(docsDevFilterIpDestPortLow.1):1.3.6.1.2.1.69.1.6.4.1.14.1, Integer, 137
SNMP MIB Object(docsDevFilterIpDestPortHigh.1):1.3.6.1.2.1.69.1.6.4.1.15.1, Integer, 139
SNMP MIB Object(docsDevFilterIpStatus.2):1.3.6.1.2.1.69.1.6.4.1.2.2, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.2):1.3.6.1.2.1.69.1.6.4.1.3.2, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.2):1.3.6.1.2.1.69.1.6.4.1.4.2, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.2):1.3.6.1.2.1.69.1.6.4.1.5.2, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.2):1.3.6.1.2.1.69.1.6.4.1.6.2, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.2):1.3.6.1.2.1.69.1.6.4.1.7.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.2):1.3.6.1.2.1.69.1.6.4.1.8.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.2):1.3.6.1.2.1.69.1.6.4.1.9.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.2):1.3.6.1.2.1.69.1.6.4.1.10.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.2):1.3.6.1.2.1.69.1.6.4.1.11.2, Integer, 17
SNMP MIB Object(docsDevFilterIpDestPortLow.2):1.3.6.1.2.1.69.1.6.4.1.14.2, Integer, 137
SNMP MIB Object(docsDevFilterIpDestPortHigh.2):1.3.6.1.2.1.69.1.6.4.1.15.2, Integer, 139
SNMP MIB Object(docsDevFilterIpStatus.3):1.3.6.1.2.1.69.1.6.4.1.2.3, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.3):1.3.6.1.2.1.69.1.6.4.1.3.3, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.3):1.3.6.1.2.1.69.1.6.4.1.4.3, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.3):1.3.6.1.2.1.69.1.6.4.1.5.3, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.3):1.3.6.1.2.1.69.1.6.4.1.6.3, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.3):1.3.6.1.2.1.69.1.6.4.1.7.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.3):1.3.6.1.2.1.69.1.6.4.1.8.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.3):1.3.6.1.2.1.69.1.6.4.1.9.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.3):1.3.6.1.2.1.69.1.6.4.1.10.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.3):1.3.6.1.2.1.69.1.6.4.1.11.3, Integer, 6
SNMP MIB Object(docsDevFilterIpDestPortLow.3):1.3.6.1.2.1.69.1.6.4.1.14.3, Integer, 135
SNMP MIB Object(docsDevFilterIpDestPortHigh.3):1.3.6.1.2.1.69.1.6.4.1.15.3, Integer, 135

Das heißt in der Folge dann auch, daß es bereits einen Mechanismus zum "Bewerten der Pakete" gibt ... das meintest Du vermutlich mit "so viel Intelligenz"?

Da wäre es dann in meinen Augen nur noch ein geringer zusätzlicher Aufwand (na gut, eine zeitabhängige Komponente käme wohl noch dazu, aber einen Timer-Service zum "Abräumen" hat Intel ja mit dem "gptimer" da ohnehin schon am Laufen), wenn man die Anzahl der neuen UDP-Flows begrenzt.

Wenn ich das Problem richtig verstanden hatte, lag es ja bereits am eCM, wenn das Gerät mit den UDP-Paketen "geflutet" werden konnte. In die Knie ging dabei ja nicht der eRouter (das wäre dann wohl der AVM-WAN-Stack in der 6x90), sondern bereits das eCM und damit waren auch alle anderen eSAFEs und nicht nur der eRouter betroffen. Wenn so ein Flow erst einmal in der Tabelle steht, gehen dessen Pakete ohne die Mitwirkung des eCM (abgesehen von der RF-seitigen Anbindung) direkt durch zur MAC-Bridge ... so habe ich das zumindest verstanden.

Da es m.W. kein valides Zugriffspattern gibt, bei dem innerhalb von wenigen Sekunden derart viele verschiedene Ports benutzt werden, dürfte es auch kein wirkliches Problem darstellen, wenn da zuvielen Paketen bzw. genauer: "unbekannten Flows" pro Zeiteinheit einfach der Hahn abgedreht wird.

Für mich wäre es eher die Frage, ob diese Limitierung (die kann sich ja jeder mit "iptables" für sein Linux auch selbst bauen) sich jetzt auf eine IP-Adresse als Absender beschränkt (dann würde das Absetzen von "störenden Paketen" mit gefälschter Absenderadresse immer noch funktionieren und das Problem wäre nur halb gelöst) oder für alle eingehenden, neuen UDP-Pakete gilt (für die bisher noch kein Eintrag in der Tabelle existiert - nach meinem Verständnis war die für diesen Eintrag (bzw. für die Reorganisation der Tabelle) benötigte Zeit das eigentliche Nadelöhr beim beschriebenen Problem).

Bei letzterem könnte man das immer noch für einen DoS-Angriff ausnutzen (auch wenn da wieder das Kosten-/Nutzen-Verhältnis eher ungünstiger wird), denn auch die FRITZ!Box verwendet halt UDP-basierte Dienste (z.B. das IPSec-VPN mit NAT-T (bzw. auch ohne, zumindest während der IKE-Phase), aber ggf. auch SIP-Steuerung), bei denen von außen tatsächlich Pakete eingehen könnten, die nicht zu einer von innen initiierten Verbindung gehören. Wenn dann die Box am Limit für neue UDP-Flows arbeitet und die legitimen UDP-Pakete dabei unterdrückt werden, wäre das sicherlich auch wieder unschön.

Da das aber Intel auch weiß, gehe ich von irgendeiner "Mischform" aus, die da auf dem eCM zusätzlich als Filterung implementiert wurde und auch immer aktiv ist, unabhängig davon, was der Provider per Config-File oder SNMP ansonsten noch so konfiguriert.

PS: Vielleicht hat Intel aber auch bloß die Anzahl der Reorganisationen der Tabelle pro Zeiteinheit begrenzt, das wäre vielleicht sogar einfacher zu realisieren (und braucht gar keinen Blick in die Pakete), allerdings wären davon dann halt wirklich alle "neuen Flows" betroffen, die nicht direkt durch die Hardware-Beschleunigung zur MAC-Bridge gelangen. Dafür wirkt das dann wohl auch bei allen Protokollen ... zumindest halte ich es auch für denkbar, daß Intel es auf diesem Weg gelöst hat oder lösen könnte. Wenn wirklich mal ein TCP-SYN unter die Räder kommt, wird das auch wiederholt und auch die von mir angesprochenen UDP-basierten Dienste haben ja i.d.R. auf einer höheren OSI-Schicht dann noch eine Fehlerkorrektur, die zumindest eine Wiederholung versuchen würde.