UPC/Magenta Connect-Box rebootet bei Aufruf von wetter.orf.at

16 Mai 2021
23
40
in Post #2 dieses Threads fiel der Satz "und wer sagt dir, dass das kein windows problem in kombination mit chromium browser ist?" ... denke die Frage ist somit geklärt.
 
6 Januar 2020
16
26
Ich kämpfe mit diesem Problem seit Ende April - ich vermute genau seit Google das Chrome Beta 91 Update ausgerollt hat.

Konnte es auch nur unter Windows 10 (PC & Notebook) mit der aktuellen Chrome Beta reproduzieren. Habe aber nie bewusst die Dynamic Port Range auf den beiden Windows Geräten umgestellt, mit denen ich getestet habe. (ist aber auf beiden Geräten auf 1024 gesetzt)
  • habe nie so etwas wie eine "Cable-Modem-Optimizer-Tool" benutzt - d.h. muss das irgendeine andere Anwendung umgestellt haben
  • am Notebook wurde Windows 10 gerade erst im Dezember komplett neu installiert.

  • Genauso wie im Blog-Post beschrieben tritt es bei mir auch nur auf Seiten von orf.at auf.
  • Über WiFi konnte ich das problem bei mir nicht reproduzieren - nur über 1G & 10G Ethernet.
  • Mit MacBook, Android Telefon tritt das Problem nicht auf

Meine temporäre Lösung für das Problem war bisher am Router der bei mir hinter der Connect Box steht (Mikrotik 4011) den Traffic für ausgehende Verbindungen zu 2a01:468:1000:9::/64 (ORF) auf 40kbit/s zu limitieren. Damit sind die ORF Seiten noch halbwegs nutzbar und die Connect Box startet nicht mehr neu.


Ich denke wenn in den nächsten Tagen Chrome 91 stable released wird, werden sicher mehr Leute das Problem haben so dass es dann evtl. auch bei Magenta ankommt.

Ich werde heute nochmal versuchen ein Script zu basteln mit dem man es Reproduzieren kann. Dass es mit dem Wiederverwenden von niedrigen Port-Nummer zu tun hat könnte der Hinweis sein, der mit noch gefehlt hat.

Wenn es eine Möglichkeit gibt um das Eindeutig zu reproduzieren kann man evtl. auch eine CVE Nummer benatragen und das "offiziell" machen - ist eindeutig Denail of Service.
 
  • Gefällt mir
Reaktionen: gunnar
9 April 2014
1.152
877
ich findes das ganze recht spannend! da sieht man mal wieder wie viel gepatzt werden kann 🤦‍♂️

auch wenn es sich ev. um eine nicht den RFCs widersprechendes Verhalten handelt, tritt das Problem scheinbar hauptsächlich bei Beta-Versionen von Browsern auf Chromium-Basis auf ... ja, es kann auch auf *NIX mittels Skript nachgestellt werden - hier sind wir von üblichen Anwendungsszenarien jedoch schon wieder weiter weg....

ich würde das Problem daher also nicht ausschließlich bei Magenta eingekippen sondern auch bei den Browser-Herstellern (am besten wohl bei den Google-Entwicklern, da die aktuell wohl am meisten zum Chromium-Entwicklung beitragen) ... diese Dev's sind übrigens oftmals auch gut mit den Hardware-Herstellern bzw. deren Firmware-Programmierern vernetzt ;)
 
18 April 2018
1.558
709
Du scheinst jetzt einen eigenen Abschnitt bezüglich Windows-Problem zu haben. Mich würd wirklich nur interessieren wer aller solche Behauptungen aufgestellt hat.

Deinem Skriptl entnehme ich, dass es weder ein Problem mit der HTTP Version ist noch mit speziellen HTTP Headern, sondern sich auf IPv6 und/oder Sourceports beschränkt. Ist das korrekt?

In dem Kontext würds mich fast überraschen wenn das ausschliesslich ein Problem bei Chrome wäre. Würd eher davon ausgehen, dass der Router allgemein Probleme hätte mit IPv6 Paketen auf "niedrigen" Ports in diesem Kontext. Vielleicht ein NAT-Gschichtl (falls NAT im IPv6 Kontext zum Zug kommt)?
 
16 Mai 2021
23
40
Die Verbindungen sind allesamt HTTPS/TLS, dass das kein HTTP (Version, Header, ...) Problem sein kann stand für mich somit von Beginn an außer Zweifel. Das Modem kann nicht in den TLS-Traffic "hineinschauen", sieht lediglich einen TLS-Handshake und dann Random-Payload.

Es gibt kein NAT mit IPv6, lediglich ein Firewalling. Egal ob man das im Modem ein oder ausschaltet, die Problematik ändert sich dadurch nicht.
 
16 Mai 2021
23
40
Ich versuche den Kenntnis-Stand in einem Satz zusammenzufassen:

Die Connect-Box hat ein generelles Problem damit, wenn mehrere (outgoing) IPv6-TCP-Connections mit gleichem quadruple {source IP address, source port number, destination IP address, destination port number} in zeitlicher Nähe stattfinden. Also: Das Wieder-Verwenden eines soeben genutzten IPv6-TCP-Source-Ports für den nochmaligen Verbindungsaufbau zum gleichen Ziel führt zum Absturz und Reboot.
 
  • Gefällt mir
Reaktionen: Forsti
2 Oktober 2015
331
272
Interessant, habe das Testskript bei mir unter Ubuntu 20.04 ausgeführt. Nach dreimaligem Durchlauf kein Problem, das Internet funktioniert weiterhin. Dann habe ich das Ethernet-Kabel abgesteckt (was vorher dran war) und war per WLAN verbunden. Ein weiterer Durchlauf brachte die Connect-Box dann beim ersten Mal zum Absturz. Die Anzeige war da gerade bei "Starte Durchlauf: 11". Scheint somit in Kombination mit WLAN aufzutreten?
 

Aktuelle Themen