{"id":1540,"date":"2021-05-22T15:36:43","date_gmt":"2021-05-22T13:36:43","guid":{"rendered":"https:\/\/hitco.at\/blog\/?p=1540"},"modified":"2022-12-18T19:42:00","modified_gmt":"2022-12-18T18:42:00","slug":"magenta-connect-box-rebootet","status":"publish","type":"post","link":"https:\/\/hitco.at\/blog\/magenta-connect-box-rebootet\/","title":{"rendered":"UPC\/Magenta Connect-Box rebootet bei Aufruf von wetter.orf.at"},"content":{"rendered":"\n<p>Ich schildere hier ein auf den ersten Blick kurios wirkendes Problem, dass sich bei n\u00e4herer 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 <a rel=\"noreferrer noopener\" href=\"https:\/\/wetter.orf.at\/oes\/\" target=\"_blank\">https:\/\/wetter.orf.at\/oes\/<\/a> mit bestimmten Web-Browser-Versionen und bestimmten Windows 10 TCP-Dynamic-Port-Range-Konfigurationen abst\u00fcrzt und neu startet. Das ist insofern sehr l\u00e4stig, als so ein Neustart mehr als 5 Minuten dauert und in dieser Zeit keine Internet-Verbindung besteht. Bis ich den Zusammenhang zwischen &#8222;mein Modem rebootet&#8220; und dem Aufruf der ORF-Wetter-WebSite erkannt habe sind einige Tage mit hoher Frustration vergangen. Bis ich schlie\u00dflich exakt die Voraussetzungen die existieren m\u00fcssen, um das Problem nachvollziehbar von jedem Windows-Ger\u00e4t aus demonstrieren zu k\u00f6nnen im Detail ergr\u00fcndet und verstanden hatte sind dann einige Stunden des Gr\u00fcbelns und Experimentierens hineingeflossen. Es handelt sich hierbei nicht um einen Einzelfall &#8222;meines Modems&#8220;, 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\u00fcr das gleiche Verbindungsziel wiederverwenden, dies l\u00e4sst sich auch mittels eines kurzen Bash-Scripts unter Linux demonstrieren. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Schritte um das Problem zu demonstrieren<\/h2>\n\n\n\n<p>Man nehme:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Einen Magenta Internet-Zugang \u00fcber Kabel mit <strong>Connect-Box&nbsp;CH7465LG-LC<\/strong>&nbsp;im&nbsp;<strong>IPv6 DS-Lite Modus<\/strong><\/li>\n\n\n\n<li>Ein <strong>Windows-10<\/strong>-Ger\u00e4t (PC, Notebook, virtuelle Maschine)<\/li>\n\n\n\n<li>\u00e4ndere den &#8222;<strong>Dynamischen TCP-Protokoll Port-Bereich<\/strong>&#8220; von Windows auf <strong>1024<\/strong>-65535 (<a href=\"#sourceportconfig\" data-type=\"internal\" data-id=\"#sourceportconfig\">siehe Anleitung unten<\/a>)<\/li>\n\n\n\n<li>installiere einen aktuellen <strong>Microsoft Edge v91<\/strong>+ oder <strong>Google Chrome v91<\/strong>+ Browser (Problem ab Version 91!)<\/li>\n\n\n\n<li>und rufe <strong><a rel=\"noreferrer noopener\" href=\"https:\/\/wetter.orf.at\/oes\/\" target=\"_blank\">https:\/\/wetter.orf.at\/oes\/<\/a> <\/strong>auf<\/li>\n\n\n\n<li>dr\u00fccke n\u00f6tigenfalls noch ein paar mal &#8222;<strong>Strg+F5<\/strong>&#8220; um die Website neu zu laden<\/li>\n<\/ul>\n\n\n\n<p><strong><span class=\"has-inline-color has-vivid-red-color\">Die Internet-Verbindung f\u00e4llt sofort aus, ein paar Sekunden sp\u00e4ter startet dann das Modem neu. <\/span><\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Was findet man hierzu im Modem-Log?<\/h3>\n\n\n\n<p>Im Modem-Log findet sich danach lediglich <strong><span class=\"has-inline-color has-vivid-purple-color\">Cable Modem Reboot &#8211; due to power reset<\/span><\/strong>, keine sonstigen Hinweise. W\u00e4re der Reboot \u00fcbrigens \u00fcber das <a rel=\"noreferrer noopener\" href=\"http:\/\/192.168.0.1\/\" target=\"_blank\">Web-Interface des Modems<\/a> ausgel\u00f6st worden oder z.B. von der Magenta-Technik \u00fcber 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\u00e4ter neu startet.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\" id=\"sourceportconfig\"><a href=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1.png\"><img loading=\"lazy\" decoding=\"async\" width=\"1096\" height=\"397\" src=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1.png\" alt=\"Web-Interface Connect-Box CH7465LG-LC\" class=\"wp-image-1619\" srcset=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1.png 1096w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1-300x109.png 300w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1-1024x371.png 1024w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1-768x278.png 768w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot-Modem-Log-1-80x29.png 80w\" sizes=\"auto, (max-width: 1096px) 100vw, 1096px\" \/><\/a><\/figure>\n\n\n\n<p id=\"dynamicports\"><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Konfiguration des &#8222;Dynamischen TCP-Protokoll Port-Bereichs&#8220; <\/h3>\n\n\n\n<p>Unter Windows 10 ist der &#8222;dynamische TCP-Protokoll Port-Bereich&#8220; standardm\u00e4\u00dfig auf 49152-65536 konfiguriert. Es handelt sich hierbei um die f\u00fcr ausgehende TCP-Verbindungen (sowohl IPv4 als auch IPv6) genutzten Source-Ports. Die Konfiguration kann wie folgt gepr\u00fcft werden:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>C:\\&gt;<strong>netsh interface ip show dynamicportrange protocol=tcp<\/strong>\n\nProtokoll tcp Dynamischer Portbereich\n---------------------------------\nStartport      : 49152\nAnzahl von Ports : 16384\n<\/code><\/pre>\n\n\n\n<p><\/p>\n\n\n\n<p>Das Problem tritt aber nur bei Verwendung <strong>&#8222;niedrigerer&#8220; TCP-Source-Port-Nummern im Bereich 1024, 1025, &#8230;<\/strong> auf. Wir \u00e4ndern die <strong>Konfiguration daher wie folgt auf auf 1024-65535<\/strong>. Eine solche Konfiguration wird auch von diversen &#8222;Windows Network-Tuning Tools&#8220; oder auch &#8222;Cable-Modem-Optimizer Tools&#8220; vorgenommen und wird auch in Microsoft-Knowledge-Base-Artikeln z.B. zum &#8222;Tuning&#8220; oder zur Vermeidung von &#8222;port exhaustion issues&#8220; erl\u00e4utert. Ich bin mit dieser Konfiguration zwar &#8222;abweichend von der Default-Konfiguration&#8220; unterwegs, aber sicherlich kein Einzelfall. Die Konfigurations\u00e4nderung wird wie folgt aus einer mit Admin-Rechten gestarteten Command-Box ausgef\u00fchrt und sogleich nochmals abgefragt und einer Sichtkontrolle unterzogen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>C:\\&gt;<strong>netsh int ip set dynamicport tcp start=1024 num=64511<\/strong>\nOK.\n\nC:\\&gt;<strong>netsh interface ip show dynamicportrange protocol=tcp<\/strong>\nProtokoll tcp Dynamischer Portbereich\n---------------------------------\nStartport      : <span class=\"has-inline-color has-vivid-red-color\"><strong>1024<\/strong><\/span>\nAnzahl von Ports : 64511<\/code><\/pre>\n\n\n\n<p><\/p>\n\n\n\n<p>Nach der \u00c4nderung sollte der verwendete Web-Browser neu gestartet werden, ein Neustart von Windows ist nicht n\u00f6tig, die Konfigurations\u00e4nderung wird sofort wirksam (und kann n\u00f6tigenfalls z.B. mittels WireShark verifiziert werden).<\/p>\n\n\n\n<p>Hinweis: Um anschlie\u00dfend nach Abschluss des Tests wieder die <strong>Windows-Default-Konfiguration<\/strong> herzustellen folgenden Befehl absetzen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>C:\\&gt;<strong>netsh int ip set dynamicport tcp start=49152 num=16384<\/strong>\nOK.\n\nC:\\&gt;<strong>netsh interface ip show dynamicportrange protocol=tcp<\/strong>\nProtokoll tcp Dynamischer Portbereich\n---------------------------------\nStartport      : <strong><span style=\"color:#04a76b\" class=\"has-inline-color\">49152<\/span><\/strong>\nAnzahl von Ports : 16384<\/code><\/pre>\n\n\n\n<p><\/p>\n\n\n\n<p>Anmerkung: Alternativ zum mittlerweile als &#8222;deprecated&#8220; eingestuften Werkzeug &#8222;<strong>netsh<\/strong>&#8220; l\u00e4sst sich das Setting auch mit der PowerShell unter Verwendung von <a rel=\"noreferrer noopener\" href=\"https:\/\/docs.microsoft.com\/en-us\/powershell\/module\/nettcpip\/set-nettcpsetting?view=windowsserver2019-ps\" target=\"_blank\"><strong>Set-NetTCPSetting<\/strong><\/a> konfigurieren. Wenn man die Settings f\u00fcr IPv4 \u00e4ndert, \u00e4ndern sich dabei auch in identischer Weise die IPv6 Settings und umgekehrt &#8211; Windows unterscheidet hier intern also offenkundig nicht.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Wireshark-Analyse<\/h3>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse.png\"><img loading=\"lazy\" decoding=\"async\" width=\"1262\" height=\"439\" src=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse.png\" alt=\"Wireshark-Analyse Connect-Box CH7465LG-LC Modem-Reboot\" class=\"wp-image-1554\" srcset=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse.png 1262w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse-300x104.png 300w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse-1024x356.png 1024w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse-768x267.png 768w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/wetter.orf_.at-Zugriff-Modemreboot2-Wireshark-Analyse-80x28.png 80w\" sizes=\"auto, (max-width: 1262px) 100vw, 1262px\" \/><\/a><\/figure>\n\n\n\n<p>Die wetter.orf.at Website ist derzeit unter folgenden IPv6 und IPv4 Adressen erreichbar, wobei der Zugriff bei mir \u00fcber 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.<\/p>\n\n\n\n<p>Nach einigem T\u00fcfteln lautet das Ergebnis meiner Analyse wie folgt:<\/p>\n\n\n\n<ol class=\"wp-block-list\" type=\"1\">\n<li>Der wetter.orf.at Server beendet die TLS-Sitzung mit einem Encrypted Alert in Paket #349<\/li>\n\n\n\n<li>Mein PC best\u00e4tigt das mit einem ACK in Paket #350 und baut mit FIN, ACK in Paket #351 die TCP-Verbindung ab.<\/li>\n\n\n\n<li>Der wetter.orf.at Server best\u00e4tigt mein Fin+ACK noch mit einem letzten ACK in Paket #616. Damit ist diese TCP-Verbindung (Port-Kombination 1024 -&gt; 443) dann auch tats\u00e4chlich beendet.<\/li>\n\n\n\n<li>Mein Edge Beta Browser baut aber die Verbindung in Paket #676 mit der gleichen Port-Kombination (1024 -&gt; 443) mit einem SYN erneut auf, Wireshark bem\u00e4ngelt dies mit einem \u201eTCP Port numbers reused\u201c (denn typischerweise sollte eine Port-Kombination nicht gleich ein paar Millisekunden sp\u00e4ter, sondern erst 30 Sekunden sp\u00e4ter re-used werden).<\/li>\n<\/ol>\n\n\n\n<p>Ich habe mehrfach reproduziert, dass das Modem stets exakt bei diesem Vorgang (Re-Using eines Ports aus der Range 1024, 1025 \u2026 1028) dann sofort nicht mehr reagiert und ca. 10sek sp\u00e4ter rebootet (LEDs werden rot, dann beginnt die Power-LED zu blinken und der Boot-Vorgang beginnt).<\/p>\n\n\n\n<p>Verwendet man &#8222;h\u00f6here TCP-Source-Ports&#8220;, also z.b. den Default von &gt;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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"browser\">Technische Detail-Informationen<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Mit welchen Web-Browsern \/ Versionen ist das Problem demonstrierbar?<\/h3>\n\n\n\n<p>Das Problem ist mit folgenden 64-bit Windows-Web-Browsern (getestet Stand 22.05.2021) demonstrierbar:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microsoft Edge Beta v91.0.864.27<\/li>\n\n\n\n<li>Microsoft Edge Beta v91.0.864.33<\/li>\n\n\n\n<li>Microsoft Edge Dev v92.0.891.1<\/li>\n\n\n\n<li>Google Chrome Beta v91.0.4472.69<\/li>\n<\/ul>\n\n\n\n<p>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 &#8222;neuer&#8220; 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\u00fcft. 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\u00e4\u00dfig noch ein paar mal (ca. 3-7 Versuche) &#8222;Strg+F5&#8220; (reload) gedr\u00fcckt um das Problem zu provozieren.<\/p>\n\n\n\n<p>Nachtrag: In der Woche vom 25.05.2021 werden die angesprochenen Beta-Versionen zu &#8222;Stable-Releases&#8220;, folgende Release-Termine wurden identifiziert und die nun als &#8222;Stable&#8220; per Online-Update in der Masse ausgerollten Versionen ebenfalls als &#8222;problematisch&#8220; identifiziert:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Chrome 91.0.4472.77<\/strong> <em>(ab 25.05.2021 ca. 21:00 per Online-Update ausgerollt!)<\/em><\/li>\n\n\n\n<li><strong>Microsoft Edge &nbsp;91.0.864.37<\/strong> (ab 27.05.2021 ca. 22:00 per Online-Update ausgerollt!)<\/li>\n<\/ul>\n\n\n\n<p id=\"modem\">Hinweis auf weitere Nachtr\u00e4ge: Siehe Abschnitt <em><a href=\"#linux\" data-type=\"internal\" data-id=\"#linux\">Problem mit Bash-Script unter Linux ebenfalls demonstrierbar!<\/a> <\/em>&#8211; hier zeige ich, dass mit  &#8222;<em>openssl s_client<\/em>&#8220; als &#8222;Browser-Ersatz&#8220; das Problem ebenfalls provoziert werden kann. Im Abschnitt <em><a href=\"https:\/\/hitco.at\/blog\/wp-admin\/post.php?post=1540&amp;action=edit#chromium\">Welcher Chromium-Change verursacht diese Verhaltens\u00e4nderung?<\/a><\/em> 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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Um welches Kabel-Modem geht es da genau?<\/h3>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"alignright\"><img loading=\"lazy\" decoding=\"async\" width=\"252\" height=\"443\" src=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/connectbox.jpg\" alt=\"Connect-Box CH7465LG-LC\" class=\"wp-image-1541\" srcset=\"https:\/\/hitco.at\/blog\/wp-content\/uploads\/connectbox.jpg 252w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/connectbox-171x300.jpg 171w, https:\/\/hitco.at\/blog\/wp-content\/uploads\/connectbox-80x141.jpg 80w\" sizes=\"auto, (max-width: 252px) 100vw, 252px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"has-text-align-left\">Um das <a rel=\"noreferrer noopener\" href=\"https:\/\/wikidevi.wi-cat.ru\/Compal_Broadband_Networks_CH7465LG-LC\" target=\"_blank\">Compal Broadband Networks CH7465LG-LC<\/a> Kabel-Modem von <strong>UPC-Telekabel<\/strong> bzw. nunmehr <strong>Magenta<\/strong>, von diesen als &#8222;<strong>Connect-Box<\/strong>&#8220; bezeichnet. Die Box ist vermutlich baugleich zu jenen von <strong>Liberty Global<\/strong> bzw. <strong>Unitymedia<\/strong> und <strong>Ziggo<\/strong>. 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\u00fcltige Firmware-Version eingesetzt:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CH7465LG-NCIP-6.12.18.25-2p6-NOSH<\/li>\n\n\n\n<li>CH7465LG-NCIP-6.12.18.26-3p7-1-NOSH <\/li>\n<\/ul>\n\n\n\n<p>Am 25.05.2021 wurde ich von einem <a rel=\"noreferrer noopener\" href=\"https:\/\/www.lteforum.at\/mobilfunk\/upc-magenta-connect-box-rebootet-bei-aufruf-von-wetter-orf-at.17418\/post-331170\" target=\"_blank\">Anwender im LTE-Forum<\/a> darauf hingewiesen, dass es eine weitere (neuere) Firmware-Version gibt, die gem\u00e4\u00df seinen Tests aber ebenfalls unver\u00e4ndert betroffen ist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CH7465LG-NCIP-6.15.28-4p9-NOSH<\/li>\n<\/ul>\n\n\n\n<p>Mein Modem arbeitet im <strong>IPv6 DS-Lite Modus<\/strong>, 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\u00fcfen konnte. (Anmerkung f\u00fcr jene, die mich belehren m\u00f6chten, dass man das Modem auch selbst im Web-Interface in den &#8222;Bridge-Modus&#8220; umkonfigurieren k\u00f6nne: Nein, das ist nur bei reiner IPv4-Konfiguration m\u00f6glich, im IPv6 DS-Lite Betrieb kann man keinen Bridge-Modus aktivieren. Und der Betriebsmodus IPv4 vs. IPv6 DS-Lite wird von Magenta \u00fcber die Konfigurationsdatei vorgegeben, ist also auch nicht vom Kunden eigenst\u00e4ndig \u00e4nderbar).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Kann es sich um einen Hardware-Defekt meines Modems handeln?<\/h3>\n\n\n\n<p id=\"firewall\">Nein, das habe ich f\u00fcr mich deshalb ausgeschlossen, weil ich das Problem mit zwei verschiedenen Modems demonstrieren kann. Urspr\u00fcnglich dachte ich tats\u00e4chlich an einen Hardware-Defekt, das Modem wurde von Magenta jedoch vollst\u00e4ndig 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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Kann das Problem durch Deaktivieren der Modem-Firewall umgangen werden?<\/h3>\n\n\n\n<p>Meinen Tests zufolge <strong>nein<\/strong>, auch wenn im Modem unter Sicherheit -&gt; Firewall die &#8222;IPv6 Firewall&#8220; deaktiviert wird besteht das Problem weiterhin. Zur Sicherheit habe ich auch &#8222;U-PNP&#8220; 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\u00f6nnten, habe ich im Web-Interface des Modems keine identifiziert.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Welche Hardware und welche Windows-Version wurde verwendet?<\/h3>\n\n\n\n<p>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 &#8222;Microsoft Mai 2021 Patchstand&#8220;.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Windows 10 v20H2<\/li>\n\n\n\n<li>Windows 10 v1909<\/li>\n\n\n\n<li>Windows 10 LTSC 2019 (entspricht v1809 Kernel)<\/li>\n<\/ul>\n\n\n\n<p>Auch die verwendete Hardware bzw. Netzwerk-Anbindung scheint unerheblich zu sein, ich kann das Problem unabh\u00e4ngig von der Hardware und unabh\u00e4ngig davon ob Ethernet oder WiFi genutzt wird demonstrieren:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>PC mit Fujitsu Mainboard, Realtek GbE Onboard (Gigabit Ethernet Adapter)<\/li>\n\n\n\n<li>Hyper-V Virtual Machine mit Hyper-V Virtual Ethernet Adapter<\/li>\n\n\n\n<li>Surface Pro Tablet mit WiFi: Marvel AVASTAR 350N<\/li>\n<\/ul>\n\n\n\n<p>Nachtrag: Siehe Abschnitt &#8222;<a href=\"https:\/\/hitco.at\/blog\/wp-admin\/post.php?post=1540&amp;action=edit#linux\">Problem mit Bash-Script unter Linux ebenfalls demonstrierbar!<\/a>&#8220; &#8211; hier zeige ich, dass mit &#8222;<em>openssl s_client<\/em>&#8220; als &#8222;Browser-Ersatz&#8220; das Problem ebenfalls provoziert werden kann.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tritt das Problem auf anderen WebSites nicht auf?<\/h3>\n\n\n\n<p>Ich kann das Problem &#8222;am besten&#8220; auf der genannten wetter.orf.at Website demonstrieren, diese Website war bei mir auch \u00f6fters 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\u00fcckkehr der ausgefallenen Internet-Verbindung selbst\u00e4ndig neu zu laden. Ihr k\u00f6nnt euch vorstellen welche Freude ich damit hatte als ich den Zusammenhang noch nicht identifiziert hatte.<\/p>\n\n\n\n<p>Ich bin mir auch sicher das Problem auf anderen orf.at Websites provozieren zu k\u00f6nnen. Mir ist das Problem bewusst bislang aber nur auf den orf.at Websites aufgefallen &#8211; 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 &#8222;TLS &#8211; Encrypted Alert&#8220; 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\u00fcndet. Ich sehe im Rahmen meiner Analyse auch keinen Grund hier den orf.at-Websites eine &#8222;Schuld&#8220; anzulasten, sie sind einfach nur ein &#8222;Mittel zur Demonstration&#8220;. Ich bin erleichtert dar\u00fcber, dass das Problem mit einer solch &#8222;unverd\u00e4chtigen&#8220; Website demonstrierbar ist, w\u00fcrde das Problem auf Schmuddel-Sites auftreten h\u00e4tte ich sonst ja nun die Schamesr\u00f6te beim Verfassen des Blog-Posts im Gesicht \ud83d\ude09<\/p>\n\n\n\n<p id=\"hairpinning\">Der Vollst\u00e4ndigkeit halber sei notiert: Auf den beiden mittels IPv6 erreichbaren Instanzen von wetter.orf.at l\u00e4uft Jetty 6.1.22 (auf den IPv4-Instanzen \u00fcbrigens 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 <a rel=\"noreferrer noopener\" href=\"https:\/\/wetter.orf.at\/oes\/\" target=\"_blank\">https:\/\/wetter.orf.at\/oes\/<\/a> abgerufenen URLs stammen von wetter.orf.at, orf.at, tubestatic.orf.at (alle drei sind mit Filter &#8222;<em>ipv6.addr==2a01:468:1000:9::108\/64<\/em>&#8220; umfasst), sowie api-tvthek.orf.at, script-at.iocnt.net und at.iocnt.net die allerdings mit IPv4-Adressen aufl\u00f6sen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Findet man zu diesem Problem nichts im Web?<\/h3>\n\n\n\n<p>Nicht exakt zu diesem Problem, aber Hinweise darauf, dass die Firmware des Modems dazu neigt bei besonderen Datenstr\u00f6men abzust\u00fcrzen und einen Neustart zu triggern findet man schon. So wird z.B. <a href=\"https:\/\/itectec.com\/superuser\/router-restarts-after-big-git-push-or-big-file-upload\/\" data-type=\"URL\" data-id=\"https:\/\/itectec.com\/superuser\/router-restarts-after-big-git-push-or-big-file-upload\/\">hier beschrieben<\/a>, dass beim Einsatz von Hairpinning\/Loopback es auch zu so einem Verhalten kommt:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\" id=\"kritisch\">\n<p><em>It&#8217;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.<\/em><\/p>\n<cite><a href=\"https:\/\/itectec.com\/superuser\/router-restarts-after-big-git-push-or-big-file-upload\/\" target=\"_blank\" rel=\"noreferrer noopener\">Router restarts after big git push or big file upload \u2013 iTecTec<\/a><\/cite><\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Ist das Problem kritisch?<\/h3>\n\n\n\n<p><strong>Aus meiner Sicht ja.<\/strong><\/p>\n\n\n\n<p>Es ist zwar nicht so kritisch wie die im Jahr 2019 publik gewordene Security-Problematik (<a rel=\"noreferrer noopener\" href=\"https:\/\/xitan.me\/posts\/connect-box-ch7465lg-rce\/\" target=\"_blank\">technische Erl\u00e4uterung von xitan<\/a>, <a rel=\"noreferrer noopener\" href=\"https:\/\/futurezone.at\/produkte\/gefaehrliche-luecke-in-magenta-routern-entdeckt\/400637039\" data-type=\"URL\" data-id=\"https:\/\/futurezone.at\/produkte\/gefaehrliche-luecke-in-magenta-routern-entdeckt\/400637039\" target=\"_blank\">FutureZone-Artikel wie Magenta damit umging<\/a>) welche durch ein Firmware-Update geschlossen wurde, aber dennoch: <\/p>\n\n\n\n<p>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: <\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Diese Beta-Versionen werden schon in k\u00fcrze zu &#8222;stable&#8220; Releases werden &#8211; z.B. wird Chrome v91 bereits am 25.05.2021 ausgerollt! Damit weitet sich der Anwender-Kreis der dieses Problem potentiell treffen k\u00f6nnte erheblich aus. <\/li>\n\n\n\n<li>Es ist v\u00f6llig unbekannt wie viele &#8222;Cable-Modem-Optimizer-Tools&#8220; im Umlauf sind, welche die Windows-Einstellungen betreffend des dynamischen TCP-Protokoll Port-Bereichs wie von mir skizziert \u00e4ndern und von Anwendern (bewusst oder unbewusst) verwendet wurden. Siehe hierzu z.B. <a rel=\"noreferrer noopener\" href=\"https:\/\/www.lteforum.at\/mobilfunk\/upc-magenta-connect-box-rebootet-bei-aufruf-von-wetter-orf-at.17418\/post-331011\" data-type=\"URL\" data-id=\"https:\/\/www.lteforum.at\/mobilfunk\/upc-magenta-connect-box-rebootet-bei-aufruf-von-wetter-orf-at.17418\/post-331011\" target=\"_blank\">eine R\u00fcckmeldung eines Anwenders die ich im LTE-Forum hierzu erhalten habe<\/a> &#8211; sein erst vor kurzem frisch installiertes Windows war ohne sein Wissen ebenfalls mit Dynamic-Ports ab 1024 konfiguriert.<\/li>\n\n\n\n<li>Das Problem ist geeignet um ein &#8222;Denial of Service&#8220; auszuf\u00fchren. Man ben\u00f6tigt keinerlei physischen Zugriff auf das Modem hierzu, auch keine Zugangsdaten zum Web-Interface. Einfach die von mir skizzierten Schritte durchf\u00fchren und die anderen Benutzer am gleichen Modem \u00e4rgern sich. Wenn man dieses Problem noch in Kombination mit dem von Magenta angebotenen &#8222;Wi-Free&#8220; betrachtet (als Magenta-Kunde kann man sich kostenfrei zu den &#8222;Wi-Free&#8220; Hotspots welche die Magenta Kabel-Modems ausstrahlen verbinden) ergibt sich daraus m\u00f6glicherweise erhebliches Potential f\u00fcr Probleme. Disclaimer: Ich habe <strong>nicht <\/strong>getestet, ob die Problematik auch \u00fcber Wi-Free zum Absturz des Routers f\u00fchrt, meine Tests wurden stets nur in meinem eigenen LAN und WLAN durchgef\u00fchrt! <\/li>\n\n\n\n<li>Probleme dieser Art tragen stets auch das Potential in sich f\u00fcr weitergehende Exploits geeignet zu sein, irgend ein Firmware-Fehler muss f\u00fcr diese Kernel-Panic die zum Reboot f\u00fchrt ja verantwortlich sein, und ob dieser nicht auch f\u00fcr andere Arten von Angriffen als nur &#8222;Denial-of-Service&#8220; ausnutzbar ist k\u00f6nnte nur ein weiterf\u00fchrender Penetrations-Test oder eine White-Box-Analyse des Source-Codes zeigen.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Was tut <span style=\"color:#e20074\" class=\"has-inline-color\">Magenta <\/span>gegen dieses Problem?<\/h2>\n\n\n\n<p>Eine Antwort auf diese Frage habe ich derzeit noch nicht. Ich habe die Thematik zwar im <a rel=\"noreferrer noopener\" href=\"https:\/\/community.magenta.at\/topic\/6917-connect-box-rebootet-bei-aufruf-von-wetterorfat\/\" data-type=\"URL\" data-id=\"https:\/\/community.magenta.at\/topic\/6917-connect-box-rebootet-bei-aufruf-von-wetterorfat\/\" target=\"_blank\">Magenta-Kundenforum<\/a> 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\u00fcckmeldung &#8222;wird sind an diesem Thema dran&#8220;. Am 27.05.2021 wurde mir mitgeteilt, das Problem w\u00e4re &#8222;an den Modem-Hersteller weitergeleitet worden&#8220; und ich solle doch auch die Browser-Hersteller informieren. Nun ja, warum mir die Aufgabe zuf\u00e4llt die Browser-Hersteller dar\u00fcber zu informieren erschlie\u00dft sich mir zwar nicht ganz, aber da ich nun mal ein guter Mensch bin habe ich das dennoch f\u00fcr <span style=\"color:#e20074\" class=\"has-inline-color\"><strong>Magenta<\/strong> <\/span>erledigt, siehe erg\u00e4nzter Abschnitt unten: <a href=\"#chromium\"><em>Welcher Chromium-Change verursacht diese Verhaltens\u00e4nderung?<\/em><\/a><\/p>\n\n\n\n<p>Falls <strong><span style=\"color:#e20074\" class=\"has-inline-color\">Magenta<\/span><span class=\"has-inline-color has-pale-pink-color\"> <\/span><\/strong>das liest: Erstens bitte beheben, zweitens mir f\u00fcr die Analyse Dank aussprechen und drittens mich f\u00fcr meine verlorene Zeit mit einer Anerkennung (kostenfreies Speed Upgrade, Paket-Nachlass, &#8230;) entsch\u00e4digen! Die Odyssee die ich beim Austausch des Modems an der Magenta-Technik-Hotline und im Magenta-Shop durchgemacht habe erl\u00e4utere ich hier \u00fcbrigens besser nicht. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Was kann ich selbst tun um das Problem zu vermeiden?<\/h2>\n\n\n\n<p>Wie oben beschrieben, die Konfiguration des &#8222;Dynamischen TCP-Protokoll Port-Bereichs&#8220; pr\u00fcfen und n\u00f6tigenfalls auf die Windows-Standard-Konfiguration zur\u00fcckstellen.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Link-Sammlung<\/h1>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a rel=\"noreferrer noopener\" href=\"https:\/\/docs.microsoft.com\/en-US\/troubleshoot\/windows-server\/networking\/default-dynamic-port-range-tcpip-chang\" target=\"_blank\">Microsoft Docs: Default Dynamic Port Range for TCP\/IP<\/a><\/li>\n\n\n\n<li><a rel=\"noreferrer noopener\" href=\"https:\/\/docs.microsoft.com\/en-us\/powershell\/module\/nettcpip\/set-nettcpsetting?view=windowsserver2019-ps\" target=\"_blank\">PowerShell Set-NetTCPSetting<\/a><\/li>\n\n\n\n<li><a rel=\"noreferrer noopener\" href=\"https:\/\/docs.microsoft.com\/en-us\/windows-server\/networking\/technologies\/network-subsystem\/net-sub-performance-tuning-nics\" target=\"_blank\">Microsoft Docs: Performance Tuning Network Adapters<\/a><\/li>\n\n\n\n<li><a rel=\"noreferrer noopener\" href=\"https:\/\/docs.microsoft.com\/en-us\/biztalk\/technical-guides\/settings-that-can-be-modified-to-improve-network-performance\" target=\"_blank\">Microsoft Docs: Improve Network Performance, Adjust MaxUserPort<\/a><\/li>\n<\/ul>\n\n\n\n<h1 class=\"wp-block-heading\">Nachtr\u00e4gliche Erg\u00e4nzungen dieses Blog-Posts<\/h1>\n\n\n\n<p>Dieser Blog-Post stammt vom Nachmittag des 22.05.2021, nachfolgend einige Erg\u00e4nzungen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>22.05.2021 19:00: Absatz <em><a href=\"#modem\" data-type=\"internal\" data-id=\"#modem\">Um welches Kabel-Modem geht es da genau?<\/a><\/em> erg\u00e4nzt: Hinweis das im IPv6 DS-Lite Modus keine Umschaltung auf &#8222;Bridge-Modus&#8220; durch Kunden m\u00f6glich ist hinzugef\u00fcgt. Weitere ISPs die das Modem nutzen erg\u00e4nzt.<\/li>\n\n\n\n<li>22.05.2021 19:30: Absatz <em><a href=\"#kritisch\" data-type=\"internal\" data-id=\"#kritisch\">Ist das Problem kritisch?<\/a><\/em> erg\u00e4nzt: Hinweis auf Firmware-Bug aus 2019 hinzugef\u00fcgt.<\/li>\n\n\n\n<li>22.05.2021 23:00: Nachfolgenden Absatz <em><a href=\"#linux\" data-type=\"internal\" data-id=\"#linux\">Problem mit Bash-Script unter Linux ebenfalls demonstrierbar!<\/a><\/em> hinzugef\u00fcgt. <\/li>\n\n\n\n<li>23.05.2021 10:30: Nachfolgenden Absatz <em><a href=\"#microsoftbug\">Das ist doch sicherlich ein Microsoft-Bug !!!111einself<\/a> <\/em>hinzugef\u00fcgt.<\/li>\n\n\n\n<li>23.05.2021 10:30: Nachfolgender Absatz <a href=\"#rfc\" data-type=\"internal\"><em>Ist dieses Verhalten RFC-konform \/ legitim?<\/em><\/a> hinzugef\u00fcgt.<\/li>\n\n\n\n<li>23.05.2021 13:15: Nachfolgender Absatz <a href=\"#ipv4\" data-type=\"internal\" data-id=\"#ipv4\"><em>Tritt das Problem nur mit IPv6 und nicht mit IPv4 auf?<\/em><\/a> hinzugef\u00fcgt.<\/li>\n\n\n\n<li>23.05.2021 14:40: Abschlie\u00dfenden Absatz <a href=\"#fazit\" data-type=\"internal\" data-id=\"#fazit\"><em>Fazit &#8211; Summary<\/em><\/a> hinzugef\u00fcgt.<\/li>\n\n\n\n<li>23.05.2021 14:40: Absatz <em><a href=\"#kritisch\">Ist das Problem kritisch?<\/a><\/em> erg\u00e4nzt: Chrome v91 wird am 25.05.2021 ausgerollt, R\u00fcckmeldung eines Anwenders aus dem LTE-Forum verlinkt.<\/li>\n\n\n\n<li>25.05.2021 21:30: Absatz <a href=\"#browser\"><em>Mit welchen Web-Browsern \/ Versionen ist das Problem demonstrierbar?<\/em><\/a> erg\u00e4nzt: Google Chrome 91.0.4472.77 ist nun per OnlineUpdate verf\u00fcgbar und ebenfalls betroffen, somit kein Beta-Browser mehr n\u00f6tig um das Problem zu demonstrieren.<\/li>\n\n\n\n<li>25.05.2021 21:40: Absatz <em><a href=\"#browser\">Um welches Kabel-Modem geht es da genau?<\/a><\/em> mit weiterer Firmware-Version erg\u00e4nzt.<\/li>\n\n\n\n<li>27.05.2021 18:30: Nachfolgender Absatz <a href=\"#chromium\"><em>Welcher Chromium-Change verursacht diese Verhaltens\u00e4nderung?<\/em><\/a> hinzugef\u00fcgt<\/li>\n\n\n\n<li>27.05.2021 19:15: Nachfolgender Absatz <a href=\"#visualstudio\"><em>Warum ist meine TCP-Source-Port-Range mit 1024 konfiguriert?<\/em><\/a> hinzugef\u00fcgt und Absatz <em><a href=\"#magenta\">Was tut Magenta gegen dieses Problem?<\/a><\/em> erg\u00e4nzt.<\/li>\n\n\n\n<li>28.05.2021 09:30: Nachfolgender Absatz <em><a href=\"#chromium\">Welcher Chromium-Change verursacht diese Verhaltens\u00e4nderung?<\/a><\/em> betreffend der Zusage seitens der Microsoft-Entwickler erg\u00e4nzt. Absatz <a href=\"#browser\"><em>Mit welchen Web-Browsern \/ Versionen ist das Problem demonstrierbar?<\/em><\/a> erg\u00e4nzt: Microsoft Edge 91.0.864.37 ist nun per OnlineUpdate verf\u00fcgbar. Ebenso den Absatz <a href=\"#fazit\"><em>Fazit &#8211; Summary<\/em><\/a> erg\u00e4nzt und Verweise auf die neuen Erkenntnisse an korrespondierenden Stellen hinzugef\u00fcgt.<\/li>\n\n\n\n<li>29.05.2021 14:30: Nachfolgenden Absatz <em><a href=\"#winsock\">Also doch ein Microsoft Bug?<\/a><\/em> hinzugef\u00fcgt.<\/li>\n\n\n\n<li>27.09.2021 18:00: Nachfolgenden Absatz <a href=\"#Status-Update-vier-Monate-spaeter\" data-type=\"internal\" data-id=\"#Status-Update-vier-Monate-spaeter\"><em>Status-Update vier Monate sp\u00e4ter<\/em><\/a> hinzugef\u00fcgt.<\/li>\n\n\n\n<li>18.12.2022 20:00: Nachfolgenden Absatz <a href=\"#Dezember-2022-Problem-behoben\">Status Dezember 2022: Problem scheint nun behoben<\/a> hinzugef\u00fcgt.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Problem mit Bash-Script unter Linux ebenfalls demonstrierbar!<\/h3>\n\n\n\n<p>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\u00fcrde: Ich habe das Problem nun kurzerhand auch unter Linux nachgestellt:<\/p>\n\n\n\n<p>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 <em>openssl s_client<\/em> einige parallele TLS-Verbindungen \u00fcber 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 &#8222;\u00fcberlebt&#8220; den Script-Druchlauf nicht, meist beim 7ten Versuch in der Schleife bricht die Internet-Verbindung weg und das Modem rebootet anschlie\u00dfend ca. 10 Sekunden sp\u00e4ter.<\/p>\n\n\n\n<pre class=\"wp-block-code has-small-font-size\"><code>#! \/bin\/bash\nmyIPv6=( $(ip -6 addr|awk '{print $2}'|grep -P '^(?!fe80)&#91;&#91;:alnum:]]{4}:.*\/64'|cut -d '\/' -f1) )\ndst=wetter.orf.at\ndstport=443\necho Stelle mehrere parallele IPv6 Verbindung zu $dst her\necho wieder-verwende hierbei die Source-Ports\necho verwende bewusst Source-Ports im Bereich 1025...1030\necho Verwendete Source-IPv6: $myIPv6\n\nfor retry in {1..15}\n  do\n    echo Starte Durchlauf: $retry\n    for srcport in {1024..1026}\n      do\n         echo Verbinde mit Source-Port $srcport\n         echo -e \"GET \/ HTTP\/1.0\\r\\nHost: $dst\\r\\n\\r\\n\" | openssl s_client -connect $dst:$dstport -6 -quiet -bind \"&#91;$myIPv6]:$srcport\" &amp;\n      done\n    # auf das Ende der bisher geforkten openssl-Prozesse warten\n    wait\n  done\necho finished.<\/code><\/pre>\n\n\n\n<p id=\"microsoftbug\">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\u00e4tigt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><em>Das ist doch sicherlich ein Microsoft-Bug <span class=\"has-inline-color has-cyan-bluish-gray-color\">!!!111einself<\/span><\/em><\/h3>\n\n\n\n<p>Diese Behauptung, es k\u00f6nne sich nur um einen Microsoft Windows und\/oder Microsoft Edge Bug handeln ist eine mehrfach gelesene Reaktion, der ich allerdings folgendes entgegenhalte:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Tritt das Problem nicht nur mit Edge Beta v91 sondern auch mit Google Chrome Beta v91 auf<\/li>\n\n\n\n<li>Kann ich das Problem &#8211; indem ich TCP-Verbindungen mit den erl\u00e4uterten Eigenschaften gezielt erzeuge &#8211; auch unter <a href=\"#linux\" data-type=\"internal\" data-id=\"#linux\">Linux unter Verwendung von <em>openssl s_client<\/em> demonstrieren<\/a><\/li>\n\n\n\n<li>Wer definiert, ob die Verhaltensweise hinsichtlich der TCP-Source-Port-Wahl eines Browsers ein &#8222;Bug&#8220; ist oder eine bewusste Design-Entscheidung? Solange das Verhaltensmuster gegen keine Normen verst\u00f6\u00dft w\u00fcrde ich es im ersten Ansatz als legitim einstufen -&gt; Details hierzu im n\u00e4chsten Absatz. Dennoch habe ich den Chromium Entwickler kontaktiert und bin der Sache nachgegangen, siehe Abschnitt: <em><a href=\"https:\/\/hitco.at\/blog\/wp-admin\/post.php?post=1540&amp;action=edit#chromium\">Welcher Chromium-Change verursacht diese Verhaltens\u00e4nderung?<\/a><\/em> sowie der nachfolgenden abschlie\u00dfenden Einordnung im Abschnitt <em><a href=\"https:\/\/hitco.at\/blog\/wp-admin\/post.php?post=1540&amp;action=edit#winsock\">Also ist doch ein Microsoft Bug?<\/a><\/em><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Ist dieses Verhalten <a href=\"https:\/\/de.wikipedia.org\/wiki\/Request_for_Comments\" target=\"_blank\" rel=\"noreferrer noopener\">RFC<\/a>-konform \/ legitim?<\/h3>\n\n\n\n<p>Die TCP-Source-Port-Nummern werden von den unterschiedlichen Implementierungen nach unterschiedlichen Algorithmen vergeben. Die <em>Ephemeral Port Range<\/em> die hierf\u00fcr zur Verf\u00fcgung steht beginnt grunds\u00e4tzlich bei 1024, jedoch unterscheidet die <a rel=\"noreferrer noopener\" href=\"http:\/\/www.iana.org\/assignments\/service-names-port-numbers\/service-names-port-numbers.xhtml\" target=\"_blank\">IANA<\/a> zwischen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Well-Known Ports, 0 &#8211; 1023<\/li>\n\n\n\n<li>Registered Ports, 1024 &#8211; 49151<\/li>\n\n\n\n<li>Dynamic \/ Private Ports, 49152 &#8211; 65535<\/li>\n<\/ul>\n\n\n\n<p>Es ist meiner Recherche zufolge nicht verboten die <em>Registered Ports<\/em> in die <em>Ephemeral Port Range<\/em> mit einzubeziehen, es gibt sogar <a rel=\"noreferrer noopener\" href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc6056\" target=\"_blank\">RFCs die dies empfehlen<\/a> um den Pool der zur Verf\u00fcgung stehenden Anzahl an Source-Port-Nummern zu erh\u00f6hen. Es muss nur gew\u00e4hrleistet sein, dass es zu keinem Konflikt mit am gleichen System gehosteten Server-Diensten kommt, welche einzelne Ports aus der Registered Port Range f\u00fcr sich nutzen.  <\/p>\n\n\n\n<p>Ebenso ist mir kein RFC bekannt der verbieten w\u00fcrde, nach Abbau einer TCP-Verbindung den gleichen TCP-Source-Port f\u00fcr den n\u00e4chsten TCP-Verbindungsaufbau wiederzuverwenden. Hinweise diesbez\u00fcglich nehme ich gerne entgegen.<\/p>\n\n\n\n<p id=\"ipv4\">Und selbst wenn es einen mir nicht bekannten RFC g\u00e4be, welcher die Nutzung von <em>Registered Ports<\/em> 1024, 1025, &#8230; als  TCP-Source-Ports untersagen w\u00fcrde, und\/oder einen RFC g\u00e4be, der vorsieht man m\u00fcsse eine gewisse Zeit lang warten bevor man einen TCP-Source-Port wiederverwendet: Selbst wenn dem so w\u00e4re, so m\u00fcsste dennoch jedes IP-taugliche und im Internet operierende Ger\u00e4t <strong>resilient <\/strong>gegen\u00fcber Netzwerkverkehr der diesen Empfehlungen widerspricht sein. Es ist absolut inakzeptabel, dass das Modem auf solchen Netzwerk-Verkehr mit einem Absturz und Reboot reagiert.<\/p>\n\n\n\n<p>Wohl aber mutet es etwas merkw\u00fcrdig an, dass die genutzten TCP-Source-Ports offenbar sequentiell selektiert werden, hier w\u00fcrde man eigentlich eine Randomisierung erwarten.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tritt das Problem nur mit IPv6 und nicht mit IPv4 auf?<\/h3>\n\n\n\n<p>Ich bin dieser Frage nun nochmals unter <a href=\"#linux\" data-type=\"internal\" data-id=\"#linux\">Verwendung des Linux-Scripts<\/a> nachgegangen. Folgende Test-Ergebnisse  konnte ich hierbei erzielen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Das Problem tritt <strong>auch mit anderen IPv6 Ziel-Servern<\/strong> auf.\n<ul class=\"wp-block-list\">\n<li>Es muss also nicht wetter.orf.at (jetty) sein.<\/li>\n\n\n\n<li>Ich habe auch mit anderen Gegenstellen (z.B. Apache auf Debian 10 als Zielserver) gleiche Ergebnisse (also Modem-Reset nach ca. 9 Durchl\u00e4ufen) erzielt.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Das Problem tritt <strong>auch mit &#8222;hohen&#8220; TCP-Source-Port-Nummern<\/strong> auf!\n<ul class=\"wp-block-list\">\n<li>In meinen Tests mit den Browsern unter Windows habe ich das Problem nur mit &#8222;niedrigen&#8220; Source-Port-Nummern bemerkt.<\/li>\n\n\n\n<li>Mit dem Linux-Script kann ich unter Verwendung von IPv6 das Problem auch mit hohen TCP-Source-Port-Nummern (51024, 51025 &#8211; also eindeutig der &#8222;Dynamic Ports&#8220; Range zuzuordnen) ebenfalls demonstrieren.  <\/li>\n\n\n\n<li>Allerdings braucht man dann offenbar ein paar Versuche mehr, nicht schon nach ca. 9 Durchl\u00e4ufen sondern erst nach 24 Durchl\u00e4ufen hat sich das Modem resettet.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Das Problem tritt in dieser Form <strong>nicht mit IPv4 Ziel-Servern<\/strong> auf.\n<ul class=\"wp-block-list\">\n<li>ABER: Bei Verwendung von IPv4 bemerke ich schon nach 2-3 Durchl\u00e4ufen eine Filterung der TCP-Connects, der erste Zugriff klapp noch, beim zweiten oder dritten kommt OpenSSL dann bei Verbindungsaufnahme nicht \u00fcber ein SYN hinaus.<\/li>\n\n\n\n<li>Das Modem st\u00fcrzt bei Verwendung eines IPv4-Zielservers <strong>nicht<\/strong> ab, es wird scheinbar nur dieser Datenverkehr selektiv gefiltert, nach einer kurzen Wartezeit (gef\u00fchlt 1 Minute) ist ein TCP-Connect dann auch wieder m\u00f6glich. <\/li>\n\n\n\n<li>Diese Filterung wird NICHT im Log des Modems protokolliert. <\/li>\n\n\n\n<li>Ein Deaktivieren der (IPv6-)Firewall im Modem mittels Web-Oberfl\u00e4che \u00e4ndert nichts an diesem Verhalten.<\/li>\n\n\n\n<li>Auch die Verwendung von &#8222;High-Ports&#8220; (51024, 41025) als Source-Port mit IPv4 \u00e4ndert nichts an dieser Filterung.<\/li>\n\n\n\n<li>Alles in allem halte ich diese IPv4-Filterung zwar f\u00fcr undurchsichtig, wird aber vermutlich irgend einen legitimen Zweck erf\u00fcllen und sollte sich in der Praxis nicht allzu problematisch auswirken.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p id=\"chromium\">Diese Tests erfolgten unter Verwendung einer Debian 10.9 VM die ans Modem \u00fcber Ethernet-Kabel angebunden ist. Als Gegenstelle wurde eine private Debian 10 Server-VM mit Apache als Web-Server gehostet in einem deutschen Rechenzentrum verwendet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Welcher Chromium-Change verursacht diese Verhaltens\u00e4nderung?<\/h2>\n\n\n\n<p id=\"visualstudio\">Ich habe den Change im Chromium-Source-Code ausfindig gemacht und den betreffenden Entwickler kontaktiert. Die Diskussion dar\u00fcber ist im <a rel=\"noreferrer noopener\" href=\"https:\/\/chromium-review.googlesource.com\/c\/chromium\/src\/+\/2727579\" target=\"_blank\">Chromium-Source-Code-Repository<\/a> nachlesbar. Die Code-\u00c4nderung wirkt sich somit auf alle Chromium-basierten Browser aus, wird daher meiner Einsch\u00e4tzung nach auch z.B. Opera oder Electron-basierte Entwicklungen unter Windows betreffen.<\/p>\n\n\n\n<p>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 \u00fcber die Kollegenschaft der Microsoft Edge Entwickler Kontakt zu Microsoft aufgenommen und positive R\u00fcckmeldung erhalten: Das Problem ist bei den Microsoft Entwicklern nachvollziehbar und wird behoben werden. Tats\u00e4chlich 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. <\/p>\n\n\n\n<p>Der &#8222;zuf\u00e4llig&#8220; beobachtete Absturz der Magenta Connect-Box beim Aufruf von bestimmten Websites wird damit zwar dann der Vergangenheit angeh\u00f6ren, aber das identifizierte Firmware-Problem des Modems muss dennoch von Compal dringend behoben werden. Die Modem-Reboot-Problematik l\u00e4sst sich &#8211; wenn man es darauf anlegt &#8211; selbst wenn Microsoft die Winsock-API \u00e4ndert dennoch weiterhin gezielt triggern (<a href=\"#linux\">siehe das zur Demonstration geeignete Bash-Script<\/a>) und somit auch f\u00fcr klassisches Denial-of-Service nutzen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Warum ist meine TCP-Source-Port-Range mit 1024 konfiguriert?<\/h2>\n\n\n\n<p id=\"fazit\">Soweit mir bekannt kann <a href=\"#dynamicports\">diese \u00c4nderung<\/a> nicht nur bewusst oder durch &#8222;Modem-Optimization-Tools&#8220; bzw. &#8222;Windows TCP-Optimization-Tools&#8220; verursacht worden sein, sondern auch Microsoft Software \u00e4ndert dieses Setting ab. In meinem Fall d\u00fcrfte z.B. die Installation von Visual Studio dieses Setting ge\u00e4ndert haben, das haben auch andere Anwender bereits beobachtet, <a rel=\"noreferrer noopener\" href=\"https:\/\/github.community\/t\/unusually-large-dynamicport-range-is-configured-for-the-github-actions-windows-latest-machine\/127130\" target=\"_blank\">siehe z.B. diese Diskussion hier<\/a>. <\/p>\n\n\n\n<p id=\"winsock\">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 &#8222;<strong>netsh int ip set dynamicport tcp start=49152 num=16384<\/strong>&#8220; genutzt werden, um diese Problematik zu umgehen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Also ist es doch ein Microsoft Bug?<\/h2>\n\n\n\n<p id=\"fazit\">Da ich <a rel=\"noreferrer noopener\" href=\"https:\/\/www.lteforum.at\/mobilfunk\/upc-magenta-connect-box-rebootet-bei-aufruf-von-wetter-orf-at.17418\/post-331527\" target=\"_blank\">einigen Hick-Hack dar\u00fcber in Foren<\/a> gelesen habe, und mehrfach mein Blog-Post sowie <a rel=\"noreferrer noopener\" href=\"https:\/\/chromium-review.googlesource.com\/c\/chromium\/src\/+\/2727579\" data-type=\"URL\" data-id=\"https:\/\/chromium-review.googlesource.com\/c\/chromium\/src\/+\/2727579\" target=\"_blank\">mein Nachrichten-Austausch mit dem zust\u00e4ndigen Chromium-Entwickler<\/a> zitiert wurde, versuche ich nochmals eine abschlie\u00dfende Einordnung der hier identifizierten Issues. Wir haben n\u00e4mlich gleich <strong>mehrere Verhaltensweisen unabh\u00e4ngig voneinander zu bem\u00e4ngeln<\/strong>, und <strong>sowohl Compal\/Magenta als auch Microsoft<\/strong> haben nun jeweils in Ihrer Verantwortung als Lieferanten ihre Hausaufgaben zu erledigen:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Das Modem darf bei der Wieder-Verwendung von IPv6-TCP-Source-Ports nicht abst\u00fcrzen und rebooten. Es braucht keine Diskussion dar\u00fcber ob ein solches Szenario doch gar nicht auftreten sollte, denn das Modem hat schlichtweg resilient dagegen zu sein, egal ob das nun ein &#8222;gutes \/ schlechtes&#8220; bzw. &#8222;gewolltes \/ unbeabsichtigtes&#8220; Port-Selection-Szenario ist oder nicht. Punkt. Diesen Aspekt kann man f\u00fcr sich genommen bereits abhaken.<\/li>\n\n\n\n<li>Warum f\u00e4llt uns das jetzt im Mai 2021 erst auf? Der Bug ist ja sicherlich schon seit Jahren in der Modem-Firmware verborgen? =&gt; Weil eine Code-\u00c4nderung im Chromium-Projekt die Source-Port-Auswahl mit Chromium v91 basierten Browsern anders l\u00f6st als dies bisher bis v90 der Fall war. Hier kommt nun unter Windows das <em>SO_RANDOMIZE_PORT<\/em>-Flag der Microsoft Windows Winsock-API zum Einsatz. Und in diesem Zusammenhang l\u00e4sst sich feststellen, dass die Winsock-API bei ge\u00e4nderter 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\u00e4nderter TCP-DynamicPort-Range die Winsock-API das tut, was die Doku beschreibt.<\/li>\n\n\n\n<li>Warum wird ein vor 50 Millisekunden geschlossener Port \u00fcberhaupt 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\u00fcrde, und indem Punkt 2 behoben wird erledigt sich somit dann auch dieser dritte Issue de-fakto gleich mit. <\/li>\n\n\n\n<li>Und warum konfiguriert das Setup-Paket von Visual Studio eigentlich ungefragt die TCP-DynamicPort-Range von Windows auf einen non-default-Wert? Die Hintergr\u00fcnde dieses Verhaltens kann man sicherlich noch n\u00e4her erforschen, aber dieses Themenfeld \u00fcberlasse ich gerne anderen. Meine Neugierde beim Visual-Studio-Team hier diesbez\u00fcglich zu recherchieren ist \u00fcberschaubar gering, zumal aus meiner Sicht grunds\u00e4tzlich nichts verwerfliches daran ist an diesem Setting zu drehen, und es durchaus Gr\u00fcnde geben d\u00fcrfte warum dies ein intendiertes Verhalten sein k\u00f6nnte.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Fazit &#8211; Summary<\/h2>\n\n\n\n<p>Die Connect-Box hat ein&nbsp;<strong>generelles Problem<\/strong>&nbsp;damit, wenn mehrere (outgoing) IPv6-TCP-Connections mit gleichem quadruple (Source-IP:Port, Destination-IP:Port) in zeitlicher N\u00e4he stattfinden. Das (mehrfache) Wieder-Verwenden eines soeben genutzten IPv6-TCP-Source-Ports f\u00fcr den nochmaligen Verbindungsaufbau binnen weniger (Milli)sekunden zum gleichen Ziel f\u00fchrt zum Absturz und Reboot. Dieser Bug in der Firmware w\u00e4re durch den Modem-Hersteller Compal zu beheben und korrigierte Firmware durch die Kabelnetz-Betreiber auszuliefern.<\/p>\n\n\n\n<p id=\"Status-Update-vier-Monate-spaeter\">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\u00f6\u00dfert wurde, also nicht der Default-Konfiguration entspricht. In diesem Zusammenhang wurde ein Winsock-API Bug identifiziert, der einer Behebung durch Microsoft zugef\u00fchrt wird.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Status-Update vier Monate sp\u00e4ter &#8211; Magenta hat weiterhin keine L\u00f6sung!<\/h2>\n\n\n\n<p>Wir schreiben den 27.09.2021, seit meiner Verfassung dieses Blog-Posts sind mehr als vier Monate vergangen. Hat Magenta das Problem inzwischen gel\u00f6st? <strong>NEIN!<\/strong><\/p>\n\n\n\n<p>Im Forum wird weiterhin nur um <a href=\"https:\/\/community.magenta.at\/topic\/6917-connect-box-rebootet-bei-aufruf-von-wetterorfat\/?do=findComment&amp;comment=44131\" data-type=\"URL\" data-id=\"https:\/\/community.magenta.at\/topic\/6917-connect-box-rebootet-bei-aufruf-von-wetterorfat\/?do=findComment&amp;comment=44131\" target=\"_blank\" rel=\"noreferrer noopener\">&#8222;Geduld&#8220; ersucht, man &#8222;arbeite daran&#8220;<\/a>.<\/p>\n\n\n\n<p id=\"Dezember-2022-Problem-behoben\">Mein Test mit aktuellem Edge v94.0.992.31 (Stable) und Modem-Firmware <strong>CH7465LG-NCIP-6.15.28-4p9-NOSH<\/strong> zeigt: Problem weiterhin unver\u00e4ndert vorhanden. Auch R\u00fcckmeldungen 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\u00fcr diesen Artikel und den Workaround danken wollen habe ich schon erhalten. Danke f\u00fcr das zahlreiche Feedback. Meine Botschaft an Magenta zu diesem Thema lautet: Sch\u00e4mt euch! Nach vier Monaten immer noch nichts zustande gebracht zu haben ist wirklich ein unw\u00fcrdiges Schauspiel!<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Status Dezember 2022: Problem scheint nun behoben<\/h2>\n\n\n\n<p>Mein Modem hat nun Firmware <strong>CH7465LG-NCIP-6.15.32p2TM-GA-NOSH<\/strong> erhalten, das Problem ist nun endlich nicht mehr vorhanden.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Modem-Firmware-Bug der von Magenta (ehemals UPC-Telekabel) eingesetzten Connect-Box f\u00fchr zu Modem Reboot. Der Firmware-Bug kommt zum Tragen, wenn ausgehende IPv6-TCP-Verbindungen in kurzem Zeitabstand den genutzten Source-Port f\u00fcr das gleiche Verbindungsziel wiederverwenden.<\/p>\n","protected":false},"author":1,"featured_media":1572,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[498,3,21,4,23],"tags":[529,526,525,524,527,530,528,198,531,201],"class_list":["post-1540","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-edge","category-it","category-netzwerk","category-security","category-windows","tag-ausfall","tag-ch7465lg-lc","tag-connect-box","tag-magenta","tag-modem","tag-neustart","tag-reboot","tag-reset","tag-stoerung","tag-upc"],"_links":{"self":[{"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/posts\/1540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/comments?post=1540"}],"version-history":[{"count":123,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/posts\/1540\/revisions"}],"predecessor-version":[{"id":1893,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/posts\/1540\/revisions\/1893"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/media\/1572"}],"wp:attachment":[{"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/media?parent=1540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/categories?post=1540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hitco.at\/blog\/wp-json\/wp\/v2\/tags?post=1540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}