Intel Puma Sicherheitslücken (Fritzbox, andere Geräte)

[robert_s]

Als Beispiel, mit meiner FritzBox 6590 (Firmware 6.85) geht mein Ping auch bis auf ~600ms hoch, wenn der Download voll ausgelastet ist

Was zeigt die Fritzbox als Hersteller des CMTS an und wer ist Dein Internetanbieter?

[philwo]

CMTS ist Casa Systems

Als Beispiel, mit meiner FritzBox 6590 (Firmware 6.85) geht mein Ping auch bis auf ~600ms hoch, wenn der Download voll ausgelastet ist

Was zeigt die Fritzbox als Hersteller des CMTS an und wer ist Dein Internetanbieter?

CMTS ist von Casa Systems (ziemlich sicher, dass das vor ~1 Monat noch Arris war), ISP ist Vodafone, Gebiet ist München-Ost.

Was denkst du ist der Grund für den hohen Ping? Bufferbloat im CMTS?

[DarkStar]

Das ist dann schon eine Docsis 3.1 fähige CMTS

[Gingerbread]

Als Beispiel, mit meiner FritzBox 6590 (Firmware 6.85) geht mein Ping auch bis auf ~600ms hoch, wenn der Download voll ausgelastet ist

Was zeigt die Fritzbox als Hersteller des CMTS an und wer ist Dein Internetanbieter?

Ich hänge mich einfach mal dran, bei mir ist es 1:1 das selbe Problem und ja es ist eindeutig (99.999% ) Bufferbloat! Ein hoch auf diesen DOCSIS 3.1 fähigen CMTS!

PING google.de (216.58.206.3): 56 data bytes
64 bytes from 216.58.206.3: icmp_seq=0 ttl=54 time=22.292 ms
64 bytes from 216.58.206.3: icmp_seq=1 ttl=54 time=24.063 ms
64 bytes from 216.58.206.3: icmp_seq=2 ttl=54 time=21.297 ms
64 bytes from 216.58.206.3: icmp_seq=3 ttl=54 time=23.961 ms
64 bytes from 216.58.206.3: icmp_seq=4 ttl=54 time=25.082 ms
64 bytes from 216.58.206.3: icmp_seq=5 ttl=54 time=18.675 ms
...
64 bytes from 216.58.206.3: icmp_seq=14 ttl=54 time=50.382 ms
64 bytes from 216.58.206.3: icmp_seq=15 ttl=54 time=88.756 ms
64 bytes from 216.58.206.3: icmp_seq=16 ttl=54 time=112.511 ms
64 bytes from 216.58.206.3: icmp_seq=17 ttl=54 time=140.616 ms
64 bytes from 216.58.206.3: icmp_seq=18 ttl=54 time=178.025 ms
64 bytes from 216.58.206.3: icmp_seq=19 ttl=54 time=215.249 ms
64 bytes from 216.58.206.3: icmp_seq=20 ttl=54 time=265.390 ms
64 bytes from 216.58.206.3: icmp_seq=21 ttl=54 time=325.693 ms
64 bytes from 216.58.206.3: icmp_seq=22 ttl=54 time=379.704 ms
64 bytes from 216.58.206.3: icmp_seq=23 ttl=54 time=431.813 ms
64 bytes from 216.58.206.3: icmp_seq=24 ttl=54 time=466.774 ms
64 bytes from 216.58.206.3: icmp_seq=25 ttl=54 time=513.301 ms
64 bytes from 216.58.206.3: icmp_seq=26 ttl=54 time=526.361 ms
64 bytes from 216.58.206.3: icmp_seq=27 ttl=54 time=547.885 ms
64 bytes from 216.58.206.3: icmp_seq=28 ttl=54 time=173.437 ms
64 bytes from 216.58.206.3: icmp_seq=29 ttl=54 time=18.475 ms
64 bytes from 216.58.206.3: icmp_seq=30 ttl=54 time=18.487 ms
64 bytes from 216.58.206.3: icmp_seq=31 ttl=54 time=20.713 ms
64 bytes from 216.58.206.3: icmp_seq=32 ttl=54 time=18.100 ms
64 bytes from 216.58.206.3: icmp_seq=33 ttl=54 time=18.688 ms
64 bytes from 216.58.206.3: icmp_seq=34 ttl=54 time=40.278 ms
64 bytes from 216.58.206.3: icmp_seq=35 ttl=54 time=36.815 ms
64 bytes from 216.58.206.3: icmp_seq=36 ttl=54 time=33.247 ms
64 bytes from 216.58.206.3: icmp_seq=37 ttl=54 time=34.581 ms
64 bytes from 216.58.206.3: icmp_seq=38 ttl=54 time=40.951 ms
64 bytes from 216.58.206.3: icmp_seq=39 ttl=54 time=40.982 ms
64 bytes from 216.58.206.3: icmp_seq=40 ttl=54 time=42.992 ms
64 bytes from 216.58.206.3: icmp_seq=41 ttl=54 time=38.143 ms
...
64 bytes from 216.58.206.3: icmp_seq=49 ttl=54 time=15.714 ms
64 bytes from 216.58.206.3: icmp_seq=50 ttl=54 time=18.144 ms
64 bytes from 216.58.206.3: icmp_seq=51 ttl=54 time=16.899 ms
64 bytes from 216.58.206.3: icmp_seq=52 ttl=54 time=20.151 ms
64 bytes from 216.58.206.3: icmp_seq=53 ttl=54 time=19.856 ms
64 bytes from 216.58.206.3: icmp_seq=54 ttl=54 time=19.128 ms
^C
--- google.de ping statistics ---
55 packets transmitted, 55 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 15.714/99.878/547.885/147.745 ms

Grün = Down / Blau = Up

Während des Downstreams liegt der Wert (Bufferbloat) in etwa zwischen 200-500ms + natürlich steigend und im Upstream besteht kein nennenswerter Bufferbloat 2-7ms.

[robert_s]

Ich hänge mich einfach mal dran, bei mir ist es 1:1 das selbe Problem und ja es ist eindeutig (99.999% ) Bufferbloat! Ein hoch auf diesen DOCSIS 3.1 fähigen CMTS!
[...]
Während des Downstreams liegt der Wert (Bufferbloat) in etwa zwischen 200-500ms + natürlich steigend und im Upstream besteht kein nennenswerter Bufferbloat 2-7ms.

Da war das Arris-CMTS einst noch schlimmer, da ging der Bufferbloat im Downstream bis auf fast 2s rauf. Also von daher ist das Casa-CMTS nicht so schlecht wie das Arris-CMTS es vor einem halben Jahr noch war.

Ich würde auch nicht ausschließen, dass da auch bei Casa mit einem Softwareupdate noch mal nachgebessert wird...

[Gingerbread]

Ich hänge mich einfach mal dran, bei mir ist es 1:1 das selbe Problem und ja es ist eindeutig (99.999% ) Bufferbloat! Ein hoch auf diesen DOCSIS 3.1 fähigen CMTS!
[...]
Während des Downstreams liegt der Wert (Bufferbloat) in etwa zwischen 200-500ms + natürlich steigend und im Upstream besteht kein nennenswerter Bufferbloat 2-7ms.

Da war das Arris-CMTS einst noch schlimmer, da ging der Bufferbloat im Downstream bis auf fast 2s rauf. Also von daher ist das Casa-CMTS nicht so schlecht wie das Arris-CMTS es vor einem halben Jahr noch war.

Ich würde auch nicht ausschließen, dass da auch bei Casa mit einem Softwareupdate noch mal nachgebessert wird...

ich denke viel mehr als hoffen, dass recht bald ein Update kommt, können wir sowieso nicht. Früher oder später wird dem wohl so sein, trotzdem unnötig, was spricht gegen eine Prüfung im vornherein..

[robert_s]

Früher oder später wird dem wohl so sein, trotzdem unnötig, was spricht gegen eine Prüfung im vornherein..

Und was hätte man dann machen sollen, nachdem man festgestellt hat, dass der Bufferbloat schlecht ist? Den DOCSIS 3.1 Ausbau verschieben, bis ein entsprechendes Softwareupdate da ist...?

[Thyrael]

Ja, warum sollte man wissentlich Ärger bei seinen Kunden verursachen? Große Anbieter nehmen ja auch entsprechende Margen an Geräten ab, da gehts ja nun nicht gerade um 3,50. Der mögliche Druck so ein Problem zu beheben ist daher groß. Aber wie Gingerbread schon schrieb, wäre die Prüfung wohl besser im Voraus gelaufen.

[spooky]

Sowas macht sich doch eher für Spieler bemerkbar und vielleicht beim Aufruf von Seiten, die zäher laden.
Also für den Großteil vernachlässigbar.

[Gingerbread]

Früher oder später wird dem wohl so sein, trotzdem unnötig, was spricht gegen eine Prüfung im vornherein..

Und was hätte man dann machen sollen, nachdem man festgestellt hat, dass der Bufferbloat schlecht ist? Den DOCSIS 3.1 Ausbau verschieben, bis ein entsprechendes Softwareupdate da ist...?

Jaein, aber nachdem dieses Vorhaben - DOCSIS 3.0 auf DOCSIS 3.1 - mit ziemlicher Sicherheit nicht erst seit 2 Monaten in Planung ist und Arris (ich bin kein CMTS-Umbau Experte) mit einem Hardwaretausch/Sonstiger Modifikation ebenso DOCSIS 3.1 fähig wäre, erscheint es mir weder logisch noch nachvollziehbar.
Natürlich treten bei solch "großen" Vorhaben immer wieder Probleme auf und dies ist auch absolut nachvollziehbar. Doch wenn ich bereits ein System habe, welches mehr oder weniger tadellos läuft (Hardwarekomponenten etc.) und dabei bleiben könnte, mit "kleinen" Veränderungen, wechselt kein normal denkender Mensch/Planer/Projektleiter diese Bestandteile gegen nicht ausführlich geprüfte Bestandteile. Selbst wenn dies nur eine Minderheit (so wenige sind das nicht, mich mit eingeschlossen ) betrifft, ist dies eigentlich, nein überhaupt kein Grund, so etwas zu veranlassen. - Mal ganz abgesehen von der Größe des Unternehmens.

Ein etwas Verwerfliches und doch sehr klares, aufschlussreiches Beispiel: Dieses Beispiel dient lediglich zu Vorführzwecken und entspricht (ich sags einfach mal..) keinesfalls der Wahrheit.

Sehr gut, dass Problem mit dem Ping/Bufferbloat betrifft kaum einen oder sie wissen nicht woran es liegt, als nächstes Prüfen wir, wie viele Rentner und im allgemeinen Kunden die Beschneidung ihrer Bandbreite feststellen, die kosten für die Segmentierungen (als hypothetischer Ansatzpunkt) sind uns einfach zu hoch. Ergebnis (Fantasiezahlen): 150 von 1000 Kunden haben sich gemeldet oder diesen ist das Problem zumindest aufgefallen, gut, beim rest verbleiben wir in diesem zustand, bis sich vielleicht doch noch jemand meldet.

@spooky (ich bin schlecht im erkennen von Ironie, wobei ich denke, dass es keine war)
Versteh mich nicht falsch, aber das lässt sich auf jeden (auch auf wichtige für manche ist es das Internet) Bereich des Lebens ausdehnen, natürlich wäre das von mir oben genannte Beispiel im höchsten maße Strafbar (usw. usw. usw. und vielleicht auch nicht ganz Realitätsnah, naja wer weiß), aber 1. wo kein Kläger, da kein Richter und 2. die Kontrolle über diese und ähnliche Entscheidungen obliegt zu meist höheren Instanzen sowie die damit einhergehende Kontrolle (AG selbst wenn die Hauptversammlung das "oberste Organ" wie bei der AG ist, trifft folgendes auch hier zu: Vorstand <- Aufsichtsrat <- Hauptversammlung <- Aktionäre ....). Die, die es wissen Interessiert es nicht und die, die es nicht wissen erfahren es auch nicht.

Im Grunde lässt sich sagen, dass ein Problem, so klein es auch sein mag, ein Problem bleibt und im schlimmsten, nur denkbaren Fall, zu einem Krebsgeschwür wird.
Da auch Arris früher teils noch schlimmere Probleme verursachte (wie bereits genannt), ist dies keinesfalls ein Grund, dass genau die gleichen, wenn auch weniger "verheerenden" Probleme wieder auftreten und das aufgrund eines Hardwarewechsels. Man sieht hier meiner Ansicht nacht ein Bild, welches sich über die Jahre abzeichnet, es wird nicht aus Fehlern gelernt, vielleicht auch nur weil es wenige betrifft und somit kein Grund für eine zukünftige Vermeidung solcher Fehler gegeben ist.

Jedem passieren Fehler, dass ist auch ganz normal, aber wenn man nie aus seinen Fehlern lernt oder auf diese hingewiesen wird, so ändert sich auch rein gar nichts. - Ignoranz, Selbstgefälligkeit oder was auch immer der Grund von VKD sein mag.