Connect-Box rebootet bei Aufruf von wetter.orf.at

[gunnar]

Das Szenario ist folgendes: Connect-Box CH7465LG-LC im IPv6 DS-Lite Modus, ein Windows 10 v20H2 PC über Ethernet angeschlossen.

 

Am PC laufen unterschiedliche Webbrowser, einer davon Microsoft Edge Beta 91.0.864.27 (das ist die derzeit am 16.05.2021 aktuelle Version).

 

Fakt ist: Wenn ich https://wetter.orf.at/oes/ aufrufe bricht die Internet-Verbindung ab (WebSite lädt bereits nicht mehr fertig, einige Grafiken fehlen noch) und einen Moment später rebootet das Modem.

 

Im Modem-Log findet sich danach lediglich Cable Modem Reboot - due to power reset, keine sonstigen Hinweise.

 

Gut, nun könnte man annehmen das Modem wäre defekt, aber nun kommts: Ich habe das Modem bereits ausgetauscht, habe nun das gleiche Modell wieder (Connect-Box CH7465LG-LC, diesmal mit "T"-Logo statt UPC-Logo an der Gehäusefront) erhalten. Problem weiterhin vorhanden.

 

Mit anderen Browsern wie Chrome, Firefox, Microsoft Edge Stable (also nicht Beta) etc... tritt das Problem nicht auf.

Nun da ich endlich draufgekommen bin was das Problem auslöst kann ich es einfach vermeiden - muss ja nicht mit Edge Beta 91.0.864.27 auf der ORF-Website das Wetter anschauen, aber da kommt man nun mal nicht so schnell drauf was die Ursache ist. Ich dachte ja tagelang bis zum Modem-Tausch es muss sich um ein Hardware-Problem am Modem handeln, erst als das Problem mit neuem Modem wieder auftrat ist mir der Zusammenhang mit dem ORF-Wetter aufgefallen und habe dies dann zahlreiche male verifiziert - hätte ich nicht für möglich gehalten. Andere problematische Website-Aufrufe sind mir noch nicht aufgefallen - solange ich nicht das ORF-Wetter abrufe läuft alles stabil und Modem-Signalwerte sowie Speedtest alles im optimalen Bereich.

 

Ausschalten der IPv6 Firewall am Modem sowie U-PNP deaktivieren ändert nichts am Verhalten.

Modem-Firmware-Update hat das Problem nicht behoben, ursprünglich war CH7465LG-NCIP-6.12.18.25-2p6-NOSH drauf, nach Update auf CH7465LG-NCIP-6.12.18.26-3p7-1-NOSH aber immer noch das gleiche Verhalten.

 

Ein Wireshark-Dump hat mich bei der Analyse bislang auch nicht weiter gebracht. Ich gehe angesichts dieser Erkenntnisse davon aus, dass es sich hier um ein Firmware-Problem des Modems bei der Analyse von IPv6 Traffic handeln muss.

 

Also, wenn euer Modem auch plötzlich rebootet und sich im Log nur "Cable Modem Reboot - due to power reset" findet, dann behaltet mal im Auge ob das mit den gleichen Website-Aufrufen die ihr unmittelbar vor dem Reboot geladen habt vielleicht auch reproduzierbar ist. 

[IT-Freak]

Würde das Netzteil mit getauscht?

Ich hatte heute erst wieder eine Leitung, wo irgendwie ein nicht passendes Netzteil im Einsatz war.

 

Es hört sich auf jeden Fall sehr spannend an

[gunnar]

Ja, Netzteil ist auch getauscht - das erhaltene Modem und Netzteil war originalverpackt. Auch das RJ45-Kabel habe ich schon getauscht.

Auch einen Einfluss der Stromversorgung schließe ich aus - andere Steckdose bereits versucht.

 

Und wie gesagt: Um das zu demonstrieren muss ich nichts anderes tun, als einfach nur die o.a. URL des ORF-Wetters mit Edge Beta aufzurufen. Frisch gebootetes Modem, ich rufe einfach nur diese URL auf und zack, Modem rebootet. Solange ich diese URL nicht aufrufe kein Problem, 5 Stunden lang Internet-Nutzung (surfen, Streamen) - alles stabil, dann ein Zugriff mit Edge-Beta auf o.a. URL und wieder zack, reboot.

 

Habe noch etwas gegoogelt und Fehlerberichte gefunden, dass Leute mit dem Modem keine größeren GIT-Push-Vorgänge mehr zustande bekommen, selber Effekt - Modem reboot. Als Lösung wurde genannt:

 

It's faulty firmware, this did not happen with CH7465LG-NCIP-6.12.18.24-5p4-NOSH. This issue is causing router restart when hairpin or loopback is being performed. With this error, you cannot use public IP or domain name inside your local network, because that is what causes reboot. It is couple of month now and still not fixed. You can ask your ISP to remotely downgrade to CH7465LG-NCIP-6.12.18.24-5p4-NOSH but the router updates itself anyway and ISP cannot stop it from doing so, so we are all screwed.

 

Wobei bei Zugriff auf die genannte Site definitiv kein Hairpinning im Spiel ist, Source (mein PC) und Destination (die Hosts die den ORF-Content ausliefern) kommunizieren beide über öffentliche IPv6-Adressen, meine Wireshark-Aufzeichnung zeigt zum betreffenden Zeitpunkt auch keinen anderen IPv4-Verkehr an - somit dürfte das Problem anders gelagert sein.

Bearbeitet Mai 16, 2021 von gunnar

[gunnar]

Nachtrag: Tritt nicht nur mit der wetter.orf.at Seite auf, sondern auch mit anderen orf.at Nachrichten-Inhalten.

Bearbeitet Mai 19, 2021 von gunnar

[gunnar]

Ich kann das Problem inzwischen auf beliebigen Windows-Geräten und auch unter Linux jederzeit zeigen, in meinem Blog-Beitrag beschreibe ich die Hintergründe und nötige Konfigurationsänderung:

UPC/Magenta Connect-Box rebootet bei Aufruf von wetter.orf.at – Blog von Gunnar Haslinger (hitco.at)

 

Bearbeitet Mai 22, 2021 von gunnar

[Christian_E]

Mach doch mal einen Hotspot von deinem Handy o.ä. und teste das wieder.
Ich hätte jetzt klar das Modem getauscht aber wenn du das schon gemacht hast und es klappt immer noch nicht, ist das mehr als interessant.
Im Prinzip aber läuft es ja mit allen anderen Browsern, evtl. ist in der Beta Version des einen Browsers echt ein heftiger Bug drinnen.
 

[gunnar]

Danke @Christian_E für den Vorschlag, den ich aber freilich längst geprüft habe.

Mit anderen Internet-Zugängen (Handy-Hotspots auf Android 11 oder iOS 14.5) tritt das Problem freilich nicht auf - es ist ein Modem-Firmware-Fehler der Connect-Box CH7465LG-LC.

 

Getriggert - wie in meinem ausführlichen Blog-Post erläutert - durch die rasche Wieder-Verwendung von niedrigen (1024, 1025, ...) TCP-Source-Port-Nummern beim Aufbau von HTTPS-Verbindungen. Das Problem ist - wie ich am Ende meines Blog-Artikels zeige - auch mit einem kleinen Linux-Shell-Script gezielt demonstrierbar. 

 

Ich kann keinen Bug darin erkennen wenn man erstens Source-Ports ab 1024 wählt, und zweitens diese nach Abbau der TCP-Verbindung sofort für eine neue wiederverwendet, mir ist kein RFC bekannt dem dies widersprechen würde, bin aber für Hinweise diesbezüglich offen. 

[Christian_E]

Alles klar. Da hast eh schon super Analysen gemacht.
Aber wie dramatisch ist es für dich? Handelt sich ja im Moment nur um ein Problem mit dem Beta Browser vom Edge.
Wird natürlich interessant zu sehen, ob die finale Version dann wieder läuft.

[gunnar]

Es geht in diesem Thread hier nicht darum meine persönliche Situation zu lösen. Ich selbst kenne die Hintergründe ja mittlerweile und weiß mir zu helfen. Aber vielen anderen Kunden geht es möglicherweise nicht so wie mir, die können sich nicht selbst helfen, bemerken lediglich das ihr Modem rebootet und wissen nicht warum. Denen soll dieser Thread und mein Blog-Post Hilfestellung bieten zu prüfen, ob sie auch von dieser Problematik betroffen sind. Und wenn ja können sie mit dieser Anleitung eine geänderte Konfiguration herstellen um das Problem erst mal zu umgehen.

 

Aber eigentlich ist Magenta jetzt am Zug und muss handeln und diesen Bug in der Firmware beheben (lassen).

 

[Christian_E]

Ja gut aber noch mal - es handelt sich um ein Problem mit nur einem Browser, der sich im Beta Stadium befindet.
Alle anderen funktionieren und selbst der Edge "stable" funktioniert.
Ob da Magenta gleich losläuft? Oder eher mal die stable Version abwartet.

Aber ich verstehe schon deinen Ansatz - proaktiv da eine Lösung zu finden, bevor es ein Massenthema wird, wäre in jedem Fall die richtige Vorgehensweise.
In jedem Fall aber Danke für deine Recherche und vor allem für die Info hier in der Community!

[gunnar]

@Christian_E Deine Einschätzung zur Dringlichkeit und hinsichtlich der Auswirkungen teile ich nicht.

 

1. Es geht nicht nur um einen Browser, sondern um zwei (Google Chrome, Microsoft Edge)

2. Der Verbreitungsgrad dieser beiden Browser ist hoch.

3. Google Chrome v91 ist nicht mehr in einer frühen Beta-Phase, sondern v91 ist bereits finalisiert und wird am 25.05.2021 (also schon in wenigen Tagen!) per Auto-Update ausgerollt. Daran ist jetzt auch gar nichts mehr zu ändern. Ich prophezeie schon jetzt, dass die Magenta-Hotline dann vermutlich ein paar Anrufe zu verzeichnen haben wird.

 

[Christian_E]

Am 16.5.2021 um 17:38 schrieb gunnar:

 

 

Mit anderen Browsern wie Chrome, Firefox, Microsoft Edge Stable (also nicht Beta) etc... tritt das Problem nicht auf.

 

Aha - ich dachte mit Chrome läuft es, wie du im Anfangspost geschrieben hast?

Bearbeitet Mai 23, 2021 von Christian_E

[Christian_E]

OK - nochmal gelesen.
Die neue Version von Chrome wird also auch Probleme machen.
Gut dann wird das definitiv ein gröberes Thema.
Ja dann kann ich auch nur hoffen, dass Magenta da mitliest....

[gunnar]

Also, Status-Update: Google Chrome 91.0.4472.77 ist nun dem Beta-Stadium entwachsen, wird seit 25.05.2021 21:00 als reguläres Google Chrome Online-Update verteilt. Problem damit - wie befürchtet - vorhanden. Könnte ab morgen also mehr Anwender geben, die mit dem Problem kämpfen. Microsoft Edge v91 ist auch noch für diese Woche angekündigt.

Magenta hat sich heute bei mir gemeldet und mitgeteilt "wir schauen uns das an". Seitdem keine Rückmeldung mehr.

 

Habe meinen Blog-Post mit den neuen Informationen aktualisiert.

 

Bearbeitet Mai 25, 2021 von gunnar

[Christian_E]

Danke für deinen Update!

[Jonathan Dorian]

Hallo @ Gunnar,

 

danke für deine vielen Infos zu diesem Thema. Unsere Technikerinnen und Techniker haben die Infos an den Modemhersteller weitergeleitet. Ich bitte dich in diesem Fall auch ein Feedback an die Anbieter der Browser zu richten, damit auch diese der Ursache auf den Grund gehen können. Halte uns hier gerne zu dem Thema am Laufenden. Liebe Grüße, Jonathan

[gunnar]

Danke @Jonathan Dorian für das Status-Update.

 

Ich weiß zwar nicht, warum Magenta denkt ich wäre dafür zuständig das an die Browser-Hersteller zu reporten, aber weil ich ein guter Mensch bin habe ich den betreffenden Change im Chromium-Projekt für euch herausgesucht und Kontakt mit dem Entwickler hergestellt. Die Diskussion ist öffentlich im Chromium-Source-Code-Repo nachvollziehbar, der Link dorthin ist in meinem Blog-Post im Abschnitt Welcher Chromium-Change verursacht diese Verhaltensänderung? ergänzt.

[gunnar]

Wie meinem aktualisierten Blog-Post zu entnehmen ist, wird basierend auf meinen Erkenntnissen nun Microsoft auch das Verhalten der Winsock-API anpassen.

 

Davon unabhängig ist nun jedoch Magenta/Compal in der Pflicht den Firmware-Bug zu beheben und ein Update bereitzustellen.

 

@Jonathan Dorian darf ich in der Sache um ein Status-Update ersuchen? Gibt es schon einen Zeithorizont hierfür seitens Compal?

 

 

[Jonathan Dorian]

Hallo @gunnar,

 

ich habe soeben nachgefragt, ob es schon News dazu gibt. Sobald ich etwas weiß, gebe ich natürlich Bescheid. Liebe Grüße, Jonathan

[nämo]

It's not a bug, it's a feature ?

 

Mal angenommen, daß das so gewollt ist. Vermutlich gibt es irgendeine Möglichkeit das Modem nicht nur von zu Hause aus, sondern auch von Außerhalb zu rebooten, um z.B. eine Fernwartung durch den Eigentümer des Modems, also den Internetanbieter, durchzuführen. Was macht dann ein halbwegs intelligenter Konfigurator einer Firewall, um z.B. das Wetter auf orf.at nicht von irgendjemandem unbefugten übers Internet ändern zu lassen ? Er integriert den Befehl zum Modemreboot in seine Firewall, wenn bestimmte Ports angesprochen werden und das Wetter bleibt, wie es ist und der vermeintliche Angreifer ärgert sich. War nur so eine Hypothese. Hat der ORF irgendwas dazu zu kommentieren ?

[Christian_E]

Interessanter Ansatz

Aber ist sowieso schräg, denn ich hab mit dem neuen Chroma nichts an Problemen mitbekommen. Bei mir läuft alles.
Und wenn da wirklich ein Problem wäre, dann müsste das schon einen ordentlichen Aufschrei in Österreich gegeben haben aber da war m.W. nichts bisher.

[gunnar]

@nämo

Jemand der autorisiert ist das Modem von außen per Fernwartung zu rebooten nutzt hierzu SNMP (der Provider) oder gibt das WebInterface hierfür von außen frei (berechtigter Nutzer des Modems). Der Provider braucht für einen Reboot von außen hierfür freilich keinen WebInterface-Zugriff und auch keinen "kreativen Workaround" wie hier offenbar vermutet. Beides hat mit diesem Issue den ich beschreibe nichts zu tun und hinterlässt im Log auch einen entsprechenden Eintrag der sich hiervon klar unterscheidet.

 

@Christian_E

Das Problem lässt sich - wie von mir beschrieben, wenn die Konfiguration der dynamic-Ports in Windows wie von mir erläutert vorgenommen wurde - auch mit Chrome 91 demonstrieren. Den "Aufschrei" gibt es deshalb nicht, weil die erläuterte Windows-Konfiguration keine Default-Konfiguration ist, und weil selbst jene bei denen das wie von mir erläutert konfiguriert ist vermutlich den Zusammenhang tagelang/wochenlang gar nicht erkennen.

 

 

Bearbeitet Juni 10, 2021 von gunnar

[Christian_E]

OK, danke noch für dein Feedback.
Damit wir es sich aber um einen relativ geringen Prozentanteil an Anwendern handeln, die da betroffen sind.
Aber natürlich - wenn man betroffen ist, dann wird dein Beitrag sicher dazu beitragen, hier Licht ins Dunkle rein zu bringen.

[IT-Freak]

Wegen Reboot über Fernwartung. Keine Ahnung wie es konkret bei Magenta abläuft, aber SNMP sollte schon am Abstellgleis stehen. TR069 wir mittlerweile sehr häufig für Fernwartung genutzt, welches auch remote Reboot und ähnliches unterstützt. (SNMP steht im Docsis Standard, wodurch es die Connect Box können müsste aber vermutlich wird die Box auch TR069 können.)

[Christian_E]

SNMP auch in den späteren Versionen (V2) ist schon klar ein Sicherheitsthema.
Haben wir in der Firma schon komplett deaktiviert.

[gunnar]

@Jonathan Dorian Du wolltest uns ja am Laufenden halten ... was hat sich denn in den letzten 3 Wochen diesbezüglich getan?