Ich schildere hier ein auf den ersten Blick kurios wirkendes Problem, dass sich bei näherer Analyse jedoch als veritabler Modem-Firmware-Bug der von Magenta (ehemals UPC-Telekabel) eingesetzten Connect-Box herausstellt. Ich kann demonstrieren, dass das Modem bei Zugriff auf https://wetter.orf.at/oes/ mit bestimmten Web-Browser-Versionen und bestimmten Windows 10 TCP-Dynamic-Port-Range-Konfigurationen abstürzt und neu startet. Das ist insofern sehr lästig, als so ein Neustart mehr als 5 Minuten dauert und in dieser Zeit keine Internet-Verbindung besteht. Bis ich den Zusammenhang zwischen „mein Modem rebootet“ und dem Aufruf der ORF-Wetter-WebSite erkannt habe sind einige Tage mit hoher Frustration vergangen. Bis ich schließlich exakt die Voraussetzungen die existieren müssen, um das Problem nachvollziehbar von jedem Windows-Gerät aus demonstrieren zu können im Detail ergründet und verstanden hatte sind dann einige Stunden des Grübelns und Experimentierens hineingeflossen. Es handelt sich hierbei nicht um einen Einzelfall „meines Modems“, sondern offenkundig um ein generelles Problem. Der Firmware-Bug kommt zum Tragen, wenn ausgehende IPv6-TCP-Verbindungen in kurzem Zeitabstand den genutzten Source-Port für das gleiche Verbindungsziel wiederverwenden, dies lässt sich auch mittels eines kurzen Bash-Scripts unter Linux demonstrieren.

Schritte um das Problem zu demonstrieren

Man nehme:

• Einen Magenta Internet-Zugang über Kabel mit Connect-Box CH7465LG-LC im IPv6 DS-Lite Modus
• Ein Windows-10-Gerät (PC, Notebook, virtuelle Maschine)
• ändere den „Dynamischen TCP-Protokoll Port-Bereich“ von Windows auf 1024-65535 (siehe Anleitung unten)
• installiere einen aktuellen Microsoft Edge v91+ oder Google Chrome v91+ Browser (Problem ab Version 91!)
• und rufe https://wetter.orf.at/oes/ auf
• drücke nötigenfalls noch ein paar mal „Strg+F5“ um die Website neu zu laden

Die Internet-Verbindung fällt sofort aus, ein paar Sekunden später startet dann das Modem neu.

Was findet man hierzu im Modem-Log?

Im Modem-Log findet sich danach lediglich Cable Modem Reboot – due to power reset, keine sonstigen Hinweise. Wäre der Reboot übrigens über das Web-Interface des Modems ausgelöst worden oder z.B. von der Magenta-Technik über SNMP Fern-Zugriff dann lautet der Log-Eintrag definitiv anders. Meine These hierzu ist, dass das Betriebssystem des Modems offenkundig an einer Kernel-Panic verstirbt und ohne hierzu etwas im Log zu hinterlassen ein paar Sekunden später neu startet.

Konfiguration des „Dynamischen TCP-Protokoll Port-Bereichs“

Unter Windows 10 ist der „dynamische TCP-Protokoll Port-Bereich“ standardmäßig auf 49152-65536 konfiguriert. Es handelt sich hierbei um die für ausgehende TCP-Verbindungen (sowohl IPv4 als auch IPv6) genutzten Source-Ports. Die Konfiguration kann wie folgt geprüft werden:

C:\>netsh interface ip show dynamicportrange protocol=tcp

Protokoll tcp Dynamischer Portbereich
---------------------------------
Startport      : 49152
Anzahl von Ports : 16384

Das Problem tritt aber nur bei Verwendung „niedrigerer“ TCP-Source-Port-Nummern im Bereich 1024, 1025, … auf. Wir ändern die Konfiguration daher wie folgt auf auf 1024-65535. Eine solche Konfiguration wird auch von diversen „Windows Network-Tuning Tools“ oder auch „Cable-Modem-Optimizer Tools“ vorgenommen und wird auch in Microsoft-Knowledge-Base-Artikeln z.B. zum „Tuning“ oder zur Vermeidung von „port exhaustion issues“ erläutert. Ich bin mit dieser Konfiguration zwar „abweichend von der Default-Konfiguration“ unterwegs, aber sicherlich kein Einzelfall. Die Konfigurationsänderung wird wie folgt aus einer mit Admin-Rechten gestarteten Command-Box ausgeführt und sogleich nochmals abgefragt und einer Sichtkontrolle unterzogen:

C:\>netsh int ip set dynamicport tcp start=1024 num=64511
OK.

C:\>netsh interface ip show dynamicportrange protocol=tcp
Protokoll tcp Dynamischer Portbereich
---------------------------------
Startport      : 1024
Anzahl von Ports : 64511

Nach der Änderung sollte der verwendete Web-Browser neu gestartet werden, ein Neustart von Windows ist nicht nötig, die Konfigurationsänderung wird sofort wirksam (und kann nötigenfalls z.B. mittels WireShark verifiziert werden).

Hinweis: Um anschließend nach Abschluss des Tests wieder die Windows-Default-Konfiguration herzustellen folgenden Befehl absetzen:

C:\>netsh int ip set dynamicport tcp start=49152 num=16384
OK.

C:\>netsh interface ip show dynamicportrange protocol=tcp
Protokoll tcp Dynamischer Portbereich
---------------------------------
Startport      : 49152
Anzahl von Ports : 16384

Anmerkung: Alternativ zum mittlerweile als „deprecated“ eingestuften Werkzeug „netsh“ lässt sich das Setting auch mit der PowerShell unter Verwendung von Set-NetTCPSetting konfigurieren. Wenn man die Settings für IPv4 ändert, ändern sich dabei auch in identischer Weise die IPv6 Settings und umgekehrt – Windows unterscheidet hier intern also offenkundig nicht.

Wireshark-Analyse

Die wetter.orf.at Website ist derzeit unter folgenden IPv6 und IPv4 Adressen erreichbar, wobei der Zugriff bei mir über IPv6 erfolgt: 2a01:468:1000:9::108, 2a01:468:1000:9::109 (bzw. IPv4: 194.232.104.109, 194.232.104.108). Diverser weiterer Content wie JavaScripts, Grafiken und Videos werden von weiteren ORF-Servern geladen, wenn man 2a01:468:1000:9::108/64 als Filter verwendet ist das (aus meiner Sicht) wichtigste jedoch umfasst.

Nach einigem Tüfteln lautet das Ergebnis meiner Analyse wie folgt:

1. Der wetter.orf.at Server beendet die TLS-Sitzung mit einem Encrypted Alert in Paket #349
2. Mein PC bestätigt das mit einem ACK in Paket #350 und baut mit FIN, ACK in Paket #351 die TCP-Verbindung ab.
3. Der wetter.orf.at Server bestätigt mein Fin+ACK noch mit einem letzten ACK in Paket #616. Damit ist diese TCP-Verbindung (Port-Kombination 1024 -> 443) dann auch tatsächlich beendet.
4. Mein Edge Beta Browser baut aber die Verbindung in Paket #676 mit der gleichen Port-Kombination (1024 -> 443) mit einem SYN erneut auf, Wireshark bemängelt dies mit einem „TCP Port numbers reused“ (denn typischerweise sollte eine Port-Kombination nicht gleich ein paar Millisekunden später, sondern erst 30 Sekunden später re-used werden).

Ich habe mehrfach reproduziert, dass das Modem stets exakt bei diesem Vorgang (Re-Using eines Ports aus der Range 1024, 1025 … 1028) dann sofort nicht mehr reagiert und ca. 10sek später rebootet (LEDs werden rot, dann beginnt die Power-LED zu blinken und der Boot-Vorgang beginnt).

Verwendet man „höhere TCP-Source-Ports“, also z.b. den Default von >49152 tritt das Problem nicht auf. Verwendet man andere Browser als die von mir problematisch identifizierten tritt das hier skizzierte Re-Usage Szenario nicht ein und das Problem tritt daher auch nicht auf.

Technische Detail-Informationen

Mit welchen Web-Browsern / Versionen ist das Problem demonstrierbar?

Das Problem ist mit folgenden 64-bit Windows-Web-Browsern (getestet Stand 22.05.2021) demonstrierbar:

• Microsoft Edge Beta v91.0.864.27
• Microsoft Edge Beta v91.0.864.33
• Microsoft Edge Dev v92.0.891.1
• Google Chrome Beta v91.0.4472.69

Das Problem tritt (mit Stand 22.05.2021) NICHT mit Edge Stable v90.0.818.62 oder Google Chrome Stable v90.0.4430.212 oder mit Firefox auf. Es muss also ein „neuer“ Browser der auf Chromium basiert ab v91 verwendet werden, die oben von mir genannten Versionen habe ich jedenfalls als geeignet um das Problem zu demonstrieren geprüft. Mit Edge Beta v91 tritt das Problem in der Regel sofort beim ersten Zugriff auf die Website schon auf, bei Verwendung von Google Chrome habe ich regelmäßig noch ein paar mal (ca. 3-7 Versuche) „Strg+F5“ (reload) gedrückt um das Problem zu provozieren.

Nachtrag: In der Woche vom 25.05.2021 werden die angesprochenen Beta-Versionen zu „Stable-Releases“, folgende Release-Termine wurden identifiziert und die nun als „Stable“ per Online-Update in der Masse ausgerollten Versionen ebenfalls als „problematisch“ identifiziert:

• Google Chrome 91.0.4472.77 (ab 25.05.2021 ca. 21:00 per Online-Update ausgerollt!)
• Microsoft Edge  91.0.864.37 (ab 27.05.2021 ca. 22:00 per Online-Update ausgerollt!)

Hinweis auf weitere Nachträge: Siehe Abschnitt Problem mit Bash-Script unter Linux ebenfalls demonstrierbar! – hier zeige ich, dass mit „openssl s_client“ als „Browser-Ersatz“ das Problem ebenfalls provoziert werden kann. Im Abschnitt Welcher Chromium-Change verursacht diese Verhaltensänderung? gehe ich der Frage auf den Grund warum die Problematik nur mit neueren Browsern ab v91 auftritt, und ob auch seitens Chromium und/oder Microsoft hier Handlungsbedarf besteht.

Um welches Kabel-Modem geht es da genau?

Um das Compal Broadband Networks CH7465LG-LC Kabel-Modem von UPC-Telekabel bzw. nunmehr Magenta, von diesen als „Connect-Box“ bezeichnet. Die Box ist vermutlich baugleich zu jenen von Liberty Global bzw. Unitymedia und Ziggo. Das Problem ist zumindest mit folgenden beiden von mir getesteten Firmware-Versionen vorhanden, letztere wird aktuell mit Stand 22.05.2021 von Magenta als letztgültige Firmware-Version eingesetzt:

• CH7465LG-NCIP-6.12.18.25-2p6-NOSH
• CH7465LG-NCIP-6.12.18.26-3p7-1-NOSH

Am 25.05.2021 wurde ich von einem Anwender im LTE-Forum darauf hingewiesen, dass es eine weitere (neuere) Firmware-Version gibt, die gemäß seinen Tests aber ebenfalls unverändert betroffen ist:

• CH7465LG-NCIP-6.15.28-4p9-NOSH

Mein Modem arbeitet im IPv6 DS-Lite Modus, ob das Problem auch in anderen Betriebs-Modi (z.B. im Bridge-Modus oder im reinen IPv4 Modus) auftritt kann ich nicht beurteilen, da ich dies bislang noch nicht prüfen konnte. (Anmerkung für jene, die mich belehren möchten, dass man das Modem auch selbst im Web-Interface in den „Bridge-Modus“ umkonfigurieren könne: Nein, das ist nur bei reiner IPv4-Konfiguration möglich, im IPv6 DS-Lite Betrieb kann man keinen Bridge-Modus aktivieren. Und der Betriebsmodus IPv4 vs. IPv6 DS-Lite wird von Magenta über die Konfigurationsdatei vorgegeben, ist also auch nicht vom Kunden eigenständig änderbar).

Kann es sich um einen Hardware-Defekt meines Modems handeln?

Nein, das habe ich für mich deshalb ausgeschlossen, weil ich das Problem mit zwei verschiedenen Modems demonstrieren kann. Ursprünglich dachte ich tatsächlich an einen Hardware-Defekt, das Modem wurde von Magenta jedoch vollständig gegen ein neues, baugleiches ausgetauscht (inkl. Netzteil, RJ45-Kabel) und das Problem war bereits mit dem alten Modem (von UPC damals am 05.01.2017 erhalten) vorhanden und ist mit dem neuen Modem (nun mit dem magenta-farbenen T-Logo statt UPC-Logo, sonst baugleich) in identischer Weise wieder vorhanden.

Kann das Problem durch Deaktivieren der Modem-Firewall umgangen werden?

Meinen Tests zufolge nein, auch wenn im Modem unter Sicherheit -> Firewall die „IPv6 Firewall“ deaktiviert wird besteht das Problem weiterhin. Zur Sicherheit habe ich auch „U-PNP“ bereits deaktiviert, aber ohne Erfolg. Weitere Einstellungen, die das Verhalten in Bezug auf TCP-Protokoll-Filterung oder Source-TCP-Ports im weiteren Sinne beeinflussen könnten, habe ich im Web-Interface des Modems keine identifiziert.

Welche Hardware und welche Windows-Version wurde verwendet?

Ich habe das Problem mit unterschiedlichen Windows-10 Releases nachvollzogen, sodass ich mir relativ sicher bin, dass die exakte Version offenkundig keine Rolle spielt. Die getesteten Windows-Versionen waren mit Stand 22.05.2021 auf aktuellem „Microsoft Mai 2021 Patchstand“.

• Windows 10 v20H2
• Windows 10 v1909
• Windows 10 LTSC 2019 (entspricht v1809 Kernel)

Auch die verwendete Hardware bzw. Netzwerk-Anbindung scheint unerheblich zu sein, ich kann das Problem unabhängig von der Hardware und unabhängig davon ob Ethernet oder WiFi genutzt wird demonstrieren:

• PC mit Fujitsu Mainboard, Realtek GbE Onboard (Gigabit Ethernet Adapter)
• Hyper-V Virtual Machine mit Hyper-V Virtual Ethernet Adapter
• Surface Pro Tablet mit WiFi: Marvel AVASTAR 350N

Nachtrag: Siehe Abschnitt „Problem mit Bash-Script unter Linux ebenfalls demonstrierbar!“ – hier zeige ich, dass mit „openssl s_client“ als „Browser-Ersatz“ das Problem ebenfalls provoziert werden kann.

Tritt das Problem auf anderen WebSites nicht auf?

Ich kann das Problem „am besten“ auf der genannten wetter.orf.at Website demonstrieren, diese Website war bei mir auch öfters in einem Tab (unbemerkt) offen geblieben und hat daher den Neustart des Modems immer wieder und wieder verursacht. Edge und Chrome haben die Eigenheit die Seite nach Rückkehr der ausgefallenen Internet-Verbindung selbständig neu zu laden. Ihr könnt euch vorstellen welche Freude ich damit hatte als ich den Zusammenhang noch nicht identifiziert hatte.

Ich bin mir auch sicher das Problem auf anderen orf.at Websites provozieren zu können. Mir ist das Problem bewusst bislang aber nur auf den orf.at Websites aufgefallen – ich vermute einen Zusammenhang mit der von den orf.at-Servern verwendeten TLS-Terminierung und der Besonderheit, dass die etablierte TLS-Verbindung nach ein paar Requests mit einem „TLS – Encrypted Alert“ beendet und von Chromium-basierten Browsern ab v91 offenkundig nun unter Wieder-Verwendung der gleichen TCP-Source-Port-Nummer wieder aufgebaut wird. Aber genauere Details hierzu habe ich nicht ergründet. Ich sehe im Rahmen meiner Analyse auch keinen Grund hier den orf.at-Websites eine „Schuld“ anzulasten, sie sind einfach nur ein „Mittel zur Demonstration“. Ich bin erleichtert darüber, dass das Problem mit einer solch „unverdächtigen“ Website demonstrierbar ist, würde das Problem auf Schmuddel-Sites auftreten hätte ich sonst ja nun die Schamesröte beim Verfassen des Blog-Posts im Gesicht 😉

Der Vollständigkeit halber sei notiert: Auf den beiden mittels IPv6 erreichbaren Instanzen von wetter.orf.at läuft Jetty 6.1.22 (auf den IPv4-Instanzen übrigens abweichend hierzu Apache) und die Verbindung wird mit mit TLS 1.2 hergestellt, das Key-Agreement erfolgt mit ECDHE_RSA mit P-256 und der Cipher ist AES_128_GCM. Soweit also eigentlich unspannend und auch nichts exotisches. Die beim Zugriff auf https://wetter.orf.at/oes/ abgerufenen URLs stammen von wetter.orf.at, orf.at, tubestatic.orf.at (alle drei sind mit Filter „ipv6.addr==2a01:468:1000:9::108/64“ umfasst), sowie api-tvthek.orf.at, script-at.iocnt.net und at.iocnt.net die allerdings mit IPv4-Adressen auflösen.

Findet man zu diesem Problem nichts im Web?

Nicht exakt zu diesem Problem, aber Hinweise darauf, dass die Firmware des Modems dazu neigt bei besonderen Datenströmen abzustürzen und einen Neustart zu triggern findet man schon. So wird z.B. hier beschrieben, dass beim Einsatz von Hairpinning/Loopback es auch zu so einem Verhalten kommt:

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.

Router restarts after big git push or big file upload – iTecTec

Ist das Problem kritisch?

Aus meiner Sicht ja.

Es ist zwar nicht so kritisch wie die im Jahr 2019 publik gewordene Security-Problematik (technische Erläuterung von xitan, FutureZone-Artikel wie Magenta damit umging) welche durch ein Firmware-Update geschlossen wurde, aber dennoch:

Das Problem trifft derzeit Anwender mit einer Windows-10-Standardkonfiguration vermutlich nicht unmittelbar. Und weiters sind derzeit die von mir identifizierten Browser Microsoft Edge ab v91 und Google Chrome ab v91 noch in Beta-Phase und werden daher noch nicht von vielen Anwendern verwendet. Aber:

1. Diese Beta-Versionen werden schon in kürze zu „stable“ Releases werden – z.B. wird Chrome v91 bereits am 25.05.2021 ausgerollt! Damit weitet sich der Anwender-Kreis der dieses Problem potentiell treffen könnte erheblich aus.
2. Es ist völlig unbekannt wie viele „Cable-Modem-Optimizer-Tools“ im Umlauf sind, welche die Windows-Einstellungen betreffend des dynamischen TCP-Protokoll Port-Bereichs wie von mir skizziert ändern und von Anwendern (bewusst oder unbewusst) verwendet wurden. Siehe hierzu z.B. eine Rückmeldung eines Anwenders die ich im LTE-Forum hierzu erhalten habe – sein erst vor kurzem frisch installiertes Windows war ohne sein Wissen ebenfalls mit Dynamic-Ports ab 1024 konfiguriert.
3. Das Problem ist geeignet um ein „Denial of Service“ auszuführen. Man benötigt keinerlei physischen Zugriff auf das Modem hierzu, auch keine Zugangsdaten zum Web-Interface. Einfach die von mir skizzierten Schritte durchführen und die anderen Benutzer am gleichen Modem ärgern sich. Wenn man dieses Problem noch in Kombination mit dem von Magenta angebotenen „Wi-Free“ betrachtet (als Magenta-Kunde kann man sich kostenfrei zu den „Wi-Free“ Hotspots welche die Magenta Kabel-Modems ausstrahlen verbinden) ergibt sich daraus möglicherweise erhebliches Potential für Probleme. Disclaimer: Ich habe nicht getestet, ob die Problematik auch über Wi-Free zum Absturz des Routers führt, meine Tests wurden stets nur in meinem eigenen LAN und WLAN durchgeführt!
4. Probleme dieser Art tragen stets auch das Potential in sich für weitergehende Exploits geeignet zu sein, irgend ein Firmware-Fehler muss für diese Kernel-Panic die zum Reboot führt ja verantwortlich sein, und ob dieser nicht auch für andere Arten von Angriffen als nur „Denial-of-Service“ ausnutzbar ist könnte nur ein weiterführender Penetrations-Test oder eine White-Box-Analyse des Source-Codes zeigen.

Was tut Magenta gegen dieses Problem?

Eine Antwort auf diese Frage habe ich derzeit noch nicht. Ich habe die Thematik zwar im Magenta-Kundenforum geschildert, es hat sich dort auch ein Moderator bei mir (privat) gemeldet und mich nach meiner Kundennummer gefragt, aber eine weitere Reaktion erfolgte bis 22.05.2021 aber bislang noch nicht. Am 25.05.2021 erhielt ich immerhin die Rückmeldung „wird sind an diesem Thema dran“. Am 27.05.2021 wurde mir mitgeteilt, das Problem wäre „an den Modem-Hersteller weitergeleitet worden“ und ich solle doch auch die Browser-Hersteller informieren. Nun ja, warum mir die Aufgabe zufällt die Browser-Hersteller darüber zu informieren erschließt sich mir zwar nicht ganz, aber da ich nun mal ein guter Mensch bin habe ich das dennoch für Magenta erledigt, siehe ergänzter Abschnitt unten: Welcher Chromium-Change verursacht diese Verhaltensänderung?

Falls Magenta das liest: Erstens bitte beheben, zweitens mir für die Analyse Dank aussprechen und drittens mich für meine verlorene Zeit mit einer Anerkennung (kostenfreies Speed Upgrade, Paket-Nachlass, …) entschädigen! Die Odyssee die ich beim Austausch des Modems an der Magenta-Technik-Hotline und im Magenta-Shop durchgemacht habe erläutere ich hier übrigens besser nicht.

Was kann ich selbst tun um das Problem zu vermeiden?

Wie oben beschrieben, die Konfiguration des „Dynamischen TCP-Protokoll Port-Bereichs“ prüfen und nötigenfalls auf die Windows-Standard-Konfiguration zurückstellen.

Link-Sammlung

• Microsoft Docs: Default Dynamic Port Range for TCP/IP
• PowerShell Set-NetTCPSetting
• Microsoft Docs: Performance Tuning Network Adapters
• Microsoft Docs: Improve Network Performance, Adjust MaxUserPort

Nachträgliche Ergänzungen dieses Blog-Posts

Dieser Blog-Post stammt vom Nachmittag des 22.05.2021, nachfolgend einige Ergänzungen:

• 22.05.2021 19:00: Absatz Um welches Kabel-Modem geht es da genau? ergänzt: Hinweis das im IPv6 DS-Lite Modus keine Umschaltung auf „Bridge-Modus“ durch Kunden möglich ist hinzugefügt. Weitere ISPs die das Modem nutzen ergänzt.
• 22.05.2021 19:30: Absatz Ist das Problem kritisch? ergänzt: Hinweis auf Firmware-Bug aus 2019 hinzugefügt.
• 22.05.2021 23:00: Nachfolgenden Absatz Problem mit Bash-Script unter Linux ebenfalls demonstrierbar! hinzugefügt.
• 23.05.2021 10:30: Nachfolgenden Absatz Das ist doch sicherlich ein Microsoft-Bug !!!111einself hinzugefügt.
• 23.05.2021 10:30: Nachfolgender Absatz Ist dieses Verhalten RFC-konform / legitim? hinzugefügt.
• 23.05.2021 13:15: Nachfolgender Absatz Tritt das Problem nur mit IPv6 und nicht mit IPv4 auf? hinzugefügt.
• 23.05.2021 14:40: Abschließenden Absatz Fazit – Summary hinzugefügt.
• 23.05.2021 14:40: Absatz Ist das Problem kritisch? ergänzt: Chrome v91 wird am 25.05.2021 ausgerollt, Rückmeldung eines Anwenders aus dem LTE-Forum verlinkt.
• 25.05.2021 21:30: Absatz Mit welchen Web-Browsern / Versionen ist das Problem demonstrierbar? ergänzt: Google Chrome 91.0.4472.77 ist nun per OnlineUpdate verfügbar und ebenfalls betroffen, somit kein Beta-Browser mehr nötig um das Problem zu demonstrieren.
• 25.05.2021 21:40: Absatz Um welches Kabel-Modem geht es da genau? mit weiterer Firmware-Version ergänzt.
• 27.05.2021 18:30: Nachfolgender Absatz Welcher Chromium-Change verursacht diese Verhaltensänderung? hinzugefügt
• 27.05.2021 19:15: Nachfolgender Absatz Warum ist meine TCP-Source-Port-Range mit 1024 konfiguriert? hinzugefügt und Absatz Was tut Magenta gegen dieses Problem? ergänzt.
• 28.05.2021 09:30: Nachfolgender Absatz Welcher Chromium-Change verursacht diese Verhaltensänderung? betreffend der Zusage seitens der Microsoft-Entwickler ergänzt. Absatz Mit welchen Web-Browsern / Versionen ist das Problem demonstrierbar? ergänzt: Microsoft Edge 91.0.864.37 ist nun per OnlineUpdate verfügbar. Ebenso den Absatz Fazit – Summary ergänzt und Verweise auf die neuen Erkenntnisse an korrespondierenden Stellen hinzugefügt.
• 29.05.2021 14:30: Nachfolgenden Absatz Also doch ein Microsoft Bug? hinzugefügt.
• 27.09.2021 18:00: Nachfolgenden Absatz Status-Update vier Monate später hinzugefügt.
• 18.12.2022 20:00: Nachfolgenden Absatz Status Dezember 2022: Problem scheint nun behoben hinzugefügt.

Problem mit Bash-Script unter Linux ebenfalls demonstrierbar!

Da ich in Foren eine gewisse Skepsis wahrgenommen habe und die Frage aufkam, ob es sich hierbei nicht vielleicht um ein reines Problem des Windows-TCP-IP-Stacks handeln würde: Ich habe das Problem nun kurzerhand auch unter Linux nachgestellt:

Mit nachfolgendem Bash-Script konnte ich das Problem auf einem Debian 10.9 System (HP Microserver mit Broadcom BCM5723 Gigabit Ethernet an Eth-Port #2 meiner Connect-Box) ebenfalls problemlos demonstrieren. Es stellt unter Verwendung von openssl s_client einige parallele TLS-Verbindungen über IPv6 zu wetter.orf.at her, und nutzt hierbei gezielt TCP-Source-Ports aus dem Bereich 1024 bis 1026 die mehrmals sofort nachdem die Verbindung abgebaut wurde wiederverwendet werden. Das Modem „überlebt“ den Script-Druchlauf nicht, meist beim 7ten Versuch in der Schleife bricht die Internet-Verbindung weg und das Modem rebootet anschließend ca. 10 Sekunden später.

#! /bin/bash
myIPv6=( $(ip -6 addr|awk '{print $2}'|grep -P '^(?!fe80)[[:alnum:]]{4}:.*/64'|cut -d '/' -f1) )
dst=wetter.orf.at
dstport=443
echo Stelle mehrere parallele IPv6 Verbindung zu $dst her
echo wieder-verwende hierbei die Source-Ports
echo verwende bewusst Source-Ports im Bereich 1025...1030
echo Verwendete Source-IPv6: $myIPv6

for retry in {1..15}
  do
    echo Starte Durchlauf: $retry
    for srcport in {1024..1026}
      do
         echo Verbinde mit Source-Port $srcport
         echo -e "GET / HTTP/1.0\r\nHost: $dst\r\n\r\n" | openssl s_client -connect $dst:$dstport -6 -quiet -bind "[$myIPv6]:$srcport" &
      done
    # auf das Ende der bisher geforkten openssl-Prozesse warten
    wait
  done
echo finished.

Somit ist aus meiner Sicht nicht nur bewiesen, dass es sich hierbei nicht um ein Problem von Windows oder der angesprochenen Browser handelt, sondern um einen Modem-Firmware-Bug der mit ein paar TCP-Verbindungen wie hier im Script gezeigt getriggert werden kann. Zugleich ist somit auch die oben im Zuge der Wireshark-Analyse aufgestellte These bestätigt.

Das ist doch sicherlich ein Microsoft-Bug !!!111einself

Diese Behauptung, es könne sich nur um einen Microsoft Windows und/oder Microsoft Edge Bug handeln ist eine mehrfach gelesene Reaktion, der ich allerdings folgendes entgegenhalte:

1. Tritt das Problem nicht nur mit Edge Beta v91 sondern auch mit Google Chrome Beta v91 auf
2. Kann ich das Problem – indem ich TCP-Verbindungen mit den erläuterten Eigenschaften gezielt erzeuge – auch unter Linux unter Verwendung von openssl s_client demonstrieren
3. Wer definiert, ob die Verhaltensweise hinsichtlich der TCP-Source-Port-Wahl eines Browsers ein „Bug“ ist oder eine bewusste Design-Entscheidung? Solange das Verhaltensmuster gegen keine Normen verstößt würde ich es im ersten Ansatz als legitim einstufen -> Details hierzu im nächsten Absatz. Dennoch habe ich den Chromium Entwickler kontaktiert und bin der Sache nachgegangen, siehe Abschnitt: Welcher Chromium-Change verursacht diese Verhaltensänderung? sowie der nachfolgenden abschließenden Einordnung im Abschnitt Also ist doch ein Microsoft Bug?

Ist dieses Verhalten RFC-konform / legitim?

Die TCP-Source-Port-Nummern werden von den unterschiedlichen Implementierungen nach unterschiedlichen Algorithmen vergeben. Die Ephemeral Port Range die hierfür zur Verfügung steht beginnt grundsätzlich bei 1024, jedoch unterscheidet die IANA zwischen:

• Well-Known Ports, 0 – 1023
• Registered Ports, 1024 – 49151
• Dynamic / Private Ports, 49152 – 65535

Es ist meiner Recherche zufolge nicht verboten die Registered Ports in die Ephemeral Port Range mit einzubeziehen, es gibt sogar RFCs die dies empfehlen um den Pool der zur Verfügung stehenden Anzahl an Source-Port-Nummern zu erhöhen. Es muss nur gewährleistet sein, dass es zu keinem Konflikt mit am gleichen System gehosteten Server-Diensten kommt, welche einzelne Ports aus der Registered Port Range für sich nutzen.

Ebenso ist mir kein RFC bekannt der verbieten würde, nach Abbau einer TCP-Verbindung den gleichen TCP-Source-Port für den nächsten TCP-Verbindungsaufbau wiederzuverwenden. Hinweise diesbezüglich nehme ich gerne entgegen.

Und selbst wenn es einen mir nicht bekannten RFC gäbe, welcher die Nutzung von Registered Ports 1024, 1025, … als TCP-Source-Ports untersagen würde, und/oder einen RFC gäbe, der vorsieht man müsse eine gewisse Zeit lang warten bevor man einen TCP-Source-Port wiederverwendet: Selbst wenn dem so wäre, so müsste dennoch jedes IP-taugliche und im Internet operierende Gerät resilient gegenüber Netzwerkverkehr der diesen Empfehlungen widerspricht sein. Es ist absolut inakzeptabel, dass das Modem auf solchen Netzwerk-Verkehr mit einem Absturz und Reboot reagiert.

Wohl aber mutet es etwas merkwürdig an, dass die genutzten TCP-Source-Ports offenbar sequentiell selektiert werden, hier würde man eigentlich eine Randomisierung erwarten.

Tritt das Problem nur mit IPv6 und nicht mit IPv4 auf?

Ich bin dieser Frage nun nochmals unter Verwendung des Linux-Scripts nachgegangen. Folgende Test-Ergebnisse konnte ich hierbei erzielen:

• Das Problem tritt auch mit anderen IPv6 Ziel-Servern auf.
  • Es muss also nicht wetter.orf.at (jetty) sein.
  • Ich habe auch mit anderen Gegenstellen (z.B. Apache auf Debian 10 als Zielserver) gleiche Ergebnisse (also Modem-Reset nach ca. 9 Durchläufen) erzielt.
• Das Problem tritt auch mit „hohen“ TCP-Source-Port-Nummern auf!
  • In meinen Tests mit den Browsern unter Windows habe ich das Problem nur mit „niedrigen“ Source-Port-Nummern bemerkt.
  • Mit dem Linux-Script kann ich unter Verwendung von IPv6 das Problem auch mit hohen TCP-Source-Port-Nummern (51024, 51025 – also eindeutig der „Dynamic Ports“ Range zuzuordnen) ebenfalls demonstrieren.
  • Allerdings braucht man dann offenbar ein paar Versuche mehr, nicht schon nach ca. 9 Durchläufen sondern erst nach 24 Durchläufen hat sich das Modem resettet.

• Das Problem tritt in dieser Form nicht mit IPv4 Ziel-Servern auf.
  • ABER: Bei Verwendung von IPv4 bemerke ich schon nach 2-3 Durchläufen eine Filterung der TCP-Connects, der erste Zugriff klapp noch, beim zweiten oder dritten kommt OpenSSL dann bei Verbindungsaufnahme nicht über ein SYN hinaus.
  • Das Modem stürzt bei Verwendung eines IPv4-Zielservers nicht ab, es wird scheinbar nur dieser Datenverkehr selektiv gefiltert, nach einer kurzen Wartezeit (gefühlt 1 Minute) ist ein TCP-Connect dann auch wieder möglich.
  • Diese Filterung wird NICHT im Log des Modems protokolliert.
  • Ein Deaktivieren der (IPv6-)Firewall im Modem mittels Web-Oberfläche ändert nichts an diesem Verhalten.
  • Auch die Verwendung von „High-Ports“ (51024, 41025) als Source-Port mit IPv4 ändert nichts an dieser Filterung.
  • Alles in allem halte ich diese IPv4-Filterung zwar für undurchsichtig, wird aber vermutlich irgend einen legitimen Zweck erfüllen und sollte sich in der Praxis nicht allzu problematisch auswirken.

Diese Tests erfolgten unter Verwendung einer Debian 10.9 VM die ans Modem über Ethernet-Kabel angebunden ist. Als Gegenstelle wurde eine private Debian 10 Server-VM mit Apache als Web-Server gehostet in einem deutschen Rechenzentrum verwendet.

Welcher Chromium-Change verursacht diese Verhaltensänderung?

Ich habe den Change im Chromium-Source-Code ausfindig gemacht und den betreffenden Entwickler kontaktiert. Die Diskussion darüber ist im Chromium-Source-Code-Repository nachlesbar. Die Code-Änderung wirkt sich somit auf alle Chromium-basierten Browser aus, wird daher meiner Einschätzung nach auch z.B. Opera oder Electron-basierte Entwicklungen unter Windows betreffen.

Der Chromium-Entwickler konnte nach kurzem Dialog binnen Minuten das von mir skizzierte problematische Verhalten (sequentielle Port-Selection sowie Port-Re-Usage) ebenfalls nachvollziehen. Er hat innerhalb weniger Stunden über die Kollegenschaft der Microsoft Edge Entwickler Kontakt zu Microsoft aufgenommen und positive Rückmeldung erhalten: Das Problem ist bei den Microsoft Entwicklern nachvollziehbar und wird behoben werden. Tatsächlich ist die beobachtete sequentielle Port-Selection ein Bug in der Winsock-API von Windows. Bei konsequenter Random-Port-Selection wird es dann statistisch betrachtet de-fakto auch nicht mehr zu einer Port-Re-Usage kommen.

Der „zufällig“ beobachtete Absturz der Magenta Connect-Box beim Aufruf von bestimmten Websites wird damit zwar dann der Vergangenheit angehören, aber das identifizierte Firmware-Problem des Modems muss dennoch von Compal dringend behoben werden. Die Modem-Reboot-Problematik lässt sich – wenn man es darauf anlegt – selbst wenn Microsoft die Winsock-API ändert dennoch weiterhin gezielt triggern (siehe das zur Demonstration geeignete Bash-Script) und somit auch für klassisches Denial-of-Service nutzen.

Warum ist meine TCP-Source-Port-Range mit 1024 konfiguriert?

Soweit mir bekannt kann diese Änderung nicht nur bewusst oder durch „Modem-Optimization-Tools“ bzw. „Windows TCP-Optimization-Tools“ verursacht worden sein, sondern auch Microsoft Software ändert dieses Setting ab. In meinem Fall dürfte z.B. die Installation von Visual Studio dieses Setting geändert haben, das haben auch andere Anwender bereits beobachtet, siehe z.B. diese Diskussion hier.

Solange Microsoft die Problematik betreffend der sequenziellen statt randomisierten Port-Auswahl durch die Winsock-API nicht behoben hat, sollte aus meiner Sicht daher dringend die Windows 10 Default-Konfiguration „netsh int ip set dynamicport tcp start=49152 num=16384“ genutzt werden, um diese Problematik zu umgehen.

Also ist es doch ein Microsoft Bug?

Da ich einigen Hick-Hack darüber in Foren gelesen habe, und mehrfach mein Blog-Post sowie mein Nachrichten-Austausch mit dem zuständigen Chromium-Entwickler zitiert wurde, versuche ich nochmals eine abschließende Einordnung der hier identifizierten Issues. Wir haben nämlich gleich mehrere Verhaltensweisen unabhängig voneinander zu bemängeln, und sowohl Compal/Magenta als auch Microsoft haben nun jeweils in Ihrer Verantwortung als Lieferanten ihre Hausaufgaben zu erledigen:

1. Das Modem darf bei der Wieder-Verwendung von IPv6-TCP-Source-Ports nicht abstürzen und rebooten. Es braucht keine Diskussion darüber ob ein solches Szenario doch gar nicht auftreten sollte, denn das Modem hat schlichtweg resilient dagegen zu sein, egal ob das nun ein „gutes / schlechtes“ bzw. „gewolltes / unbeabsichtigtes“ Port-Selection-Szenario ist oder nicht. Punkt. Diesen Aspekt kann man für sich genommen bereits abhaken.
2. Warum fällt uns das jetzt im Mai 2021 erst auf? Der Bug ist ja sicherlich schon seit Jahren in der Modem-Firmware verborgen? => Weil eine Code-Änderung im Chromium-Projekt die Source-Port-Auswahl mit Chromium v91 basierten Browsern anders löst als dies bisher bis v90 der Fall war. Hier kommt nun unter Windows das SO_RANDOMIZE_PORT-Flag der Microsoft Windows Winsock-API zum Einsatz. Und in diesem Zusammenhang lässt sich feststellen, dass die Winsock-API bei geänderter TCP-DynamicPort-Range hier entgegen der API-Dokumentation die Ports nicht (mehr) randomisiert sondern sequentiell vergibt. Und da die betreffende Winsock-API von Microsoft bereitgestellt wird, ist hier Microsoft am Ball dieses nicht der Dokumentation entsprechende Verhalten anzupassen, sodass auch mit geänderter TCP-DynamicPort-Range die Winsock-API das tut, was die Doku beschreibt.
3. Warum wird ein vor 50 Millisekunden geschlossener Port überhaupt gleich wiederverwendet? Das ist nicht verboten, das Modem darf sich daran nicht verschlucken. Aber auch hier ist festzuhalten, dass man bei randomisierter Port-Auswahl eigentlich statistisch gesehen ein anderes Verhalten erwarten würde, und indem Punkt 2 behoben wird erledigt sich somit dann auch dieser dritte Issue de-fakto gleich mit.
4. Und warum konfiguriert das Setup-Paket von Visual Studio eigentlich ungefragt die TCP-DynamicPort-Range von Windows auf einen non-default-Wert? Die Hintergründe dieses Verhaltens kann man sicherlich noch näher erforschen, aber dieses Themenfeld überlasse ich gerne anderen. Meine Neugierde beim Visual-Studio-Team hier diesbezüglich zu recherchieren ist überschaubar gering, zumal aus meiner Sicht grundsätzlich nichts verwerfliches daran ist an diesem Setting zu drehen, und es durchaus Gründe geben dürfte warum dies ein intendiertes Verhalten sein könnte.

Fazit – Summary

Die Connect-Box hat ein generelles Problem damit, wenn mehrere (outgoing) IPv6-TCP-Connections mit gleichem quadruple (Source-IP:Port, Destination-IP:Port) in zeitlicher Nähe stattfinden. Das (mehrfache) Wieder-Verwenden eines soeben genutzten IPv6-TCP-Source-Ports für den nochmaligen Verbindungsaufbau binnen weniger (Milli)sekunden zum gleichen Ziel führt zum Absturz und Reboot. Dieser Bug in der Firmware wäre durch den Modem-Hersteller Compal zu beheben und korrigierte Firmware durch die Kabelnetz-Betreiber auszuliefern.

Das Problem tritt unter anderem dann demonstrierbar beim Aufruf relevanter Websites auf, wenn Chromium-basierte Browser ab v91 genutzt werden und die TCP-DynamicPort-Range von Windows vergrößert wurde, also nicht der Default-Konfiguration entspricht. In diesem Zusammenhang wurde ein Winsock-API Bug identifiziert, der einer Behebung durch Microsoft zugeführt wird.

Status-Update vier Monate später – Magenta hat weiterhin keine Lösung!

Wir schreiben den 27.09.2021, seit meiner Verfassung dieses Blog-Posts sind mehr als vier Monate vergangen. Hat Magenta das Problem inzwischen gelöst? NEIN!

Im Forum wird weiterhin nur um „Geduld“ ersucht, man „arbeite daran“.

Mein Test mit aktuellem Edge v94.0.992.31 (Stable) und Modem-Firmware CH7465LG-NCIP-6.15.28-4p9-NOSH zeigt: Problem weiterhin unverändert vorhanden. Auch Rückmeldungen in zahlreichen Foren, hier im Blog als Kommentar und per E-Mail gehen bei mir immer noch ein. Ja sogar Telefon-Anrufe von Menschen die mir für diesen Artikel und den Workaround danken wollen habe ich schon erhalten. Danke für das zahlreiche Feedback. Meine Botschaft an Magenta zu diesem Thema lautet: Schämt euch! Nach vier Monaten immer noch nichts zustande gebracht zu haben ist wirklich ein unwürdiges Schauspiel!

Status Dezember 2022: Problem scheint nun behoben

Mein Modem hat nun Firmware CH7465LG-NCIP-6.15.32p2TM-GA-NOSH erhalten, das Problem ist nun endlich nicht mehr vorhanden.