Categories:

Mein Amazon FireTV-Stick verliert ständig die Verbindung. Liegt es am WLAN? [GELÖST]

Veröffentlicht von empy
Lesezeit: 7 Minuten

Seit Monaten treibt er mich in den Wahnsinn: Mein FireTV-Stick. Dabei verrichtete der Stick schon mehrere Jahre ohne zu murren seinen Dienst. Auch den Wechsel meiner Access Points hat er problemlos akzeptiert. Und selbst die Einführung von VLANs in meinem Heimnetzwerk war absolut kein Thema. Doch nun funktioniert er nicht mehr richtig.

Der FireTV-Stick findet keine Verbindung zum Internet. Verbindung fehlgeschlagen! Wo liegt das Problem? WLAN, Firewall, Provider, Amazon? Na, das kann ja heiter werden. Aber es hilft ja nichts. Seit Monaten ärgert mich das Thema. Und es ärgert mich richtig, denn der Fehler tritt nur manchmal auf. An guten Tagen funktioniert alles so, als hätte nie ein Problem existiert. Sonst hätte ich vielleicht schon früher reagiert.

Vermutungen können in die Irre führen!

Also sollte ich das Problem nun endlich ordentlich lösen. Das kann ja nicht so schwer sein, denn ich habe seit Längerem einen Verdacht: Kurz vor dem Beginn der Probleme hatte ich ein Update meiner Aruba Instant Access Points auf die Version 8.4 eingespielt. Der FireTV-Stick (wie auch alle anderen Clients im Netzwerk) hat danach zwar gut funktioniert, aber sonst hat sich nichts im Netzwerk verändert!? Bestimmt liegt es also daran.

Der FireTV-Stick selbst zeigt vorhandene Konnektivität zum WLAN an, aber vielleicht bekommt er keine IP-Adresse oder die Verbindung ist instabil. Denn WLAN-Konnektivität ist nicht gleich Internet-Konnektivität, schließlich ist WLAN im Prinzip nur ein Zugriffsweg, um überhaupt erst ins Netzwerk zu gelangen. Dieser Umstand macht WLAN oft zum Sündenbock für allerlei Netzwerkprobleme, auch wenn das Problem an ganz anderer Stelle liegt. Glücklicherweise ist das aber schnell überprüft. Dazu genügt ein kurzer Blick in das Web-Interface der Aruba Instant Access Points.

WLAN in Ordnung? Aruba Instant zeigt erste Infos.

Hier ist soweit eigentlich alles einwandfrei. IP-Adresse vorhanden, die Funkstatistiken sind auch in Ordnung. Lediglich die eingehenden Retries stechen ins Auge. Insgesamt meiner Meinung nach nichts wirklich Beunruhigendes. Auch der Uplink ist online.

Wenn es nicht am WLAN liegt, dann könnte noch die Firewall als mögliche Fehlerursache in Frage kommen. Aber auch hier finden sich keine Auffälligkeiten in den Logfiles, welche sich auf den FireTV-Stick beziehen: Ein paar gedroppte Pakete im Webfilter und der Fehler „Could not associate packet to any connection“ bei Regel 0. Über diese Fehler hatte ich seinerzeit bei der Einrichtung der Firewall vergeblich gegoogelt. Der FireTV-Stick hat bisher immer trotzdem problemlos funktioniert, nachdem ich damals für den FireTV-Stick eine Ausnahme für das CDN von Akamai angelegt hatte.
Aber ich muss zugeben: So ganz im Griff habe ich den Log-Viewer der Sophos XG noch nicht. Das hatte ich mit meiner alten Firewall, die auf Mikrotik und iptables basierte, besser im Griff. Aber ich musste ja unbedingt diese tollen Features einer next-gen-Firewall ausprobieren. Wie dem auch sei, den Logdateien konnte ich keine wirklich hilfreichen Informationen entnehmen.

Firewall-Logs der Sophos XG.

Schluss mit dem Rätselraten: Paket-Analyse mit Wireshark

So komme ich nicht weiter. WLAN, mehrere Switche, Router und Firewall. Das ist eine Fahrt ins Blaue. Die endgültige Lösung muss endlich her. Und dafür muss die Ursache klar sein. Wie im Artikel zum Packet Capturing unter Aruba Instant beschrieben, habe ich unter Anwendung des Capture-Filters einen Paketmitschnitt erstellt.

udp port 5555

Das macht die Arbeit im *.pcap-File um ein Vielfaches einfacher. Mit dem Display-Filter „ip.addr == 19.168.26.17“ werden die Pakete dann auf den FireTV-Stick eingegrenzt.

Paketmitschnitt in Wireshark. Ist das des Rätsels Lösung?

Schaut man sich die Frames an, stechen vor allem zwei Dinge schnell ins Auge. Zum einen werden sehr viele TCP-Retransmissions übermittelt, zum anderen treten wiederholt TCP-Resets auf. Die TCP-Retransmissions sind bereits vorhin in der Statistik von Aruba Instant aufgetaucht und für WLAN aufgrund des shared mediums nichts Besonderes. Deshalb geht es mir im nächsten Schritt vor allem um die TCP-Resets. Mit dem Display-Filter „tcp.flags.reset == 1“ kommt man hier gut ans Ziel. Kombiniert lautet der Display-Filter dann wie folgt:

ip.addr == 19.168.26.17 && tcp.flags.reset == 1
TCP-Resets gefiltert in Wireshark.

Sehr schnell sichtbar wird nun Folgendes: Ein Teil der TCP-Resets wird offenbar durch meine Sophos XG Firewall erzeugt. Dies ist sehr gut an der IP-Adresse der Firewall sowie deren MAC-Adresse erkennbar. Der andere Teil der TCP-Resets stammt von mir unbekannten IP-Adressen aus dem Internet. Der Wert „Time to Live“ im IP-Header (Layer 3) bei vielen Frames aus dem Internet weist interessanterweise darauf hin, dass der TCP-Reset in diesen Fällen nicht durch einen Webserver selbst verursacht wurden, sondern meine Firewall das Paket manipuliert hat. Meine Access Points scheinen übrigens keine Rolle bei der Verursachung der TCP-Resets zu spielen.

TTL-Debugging von TCP-Resets.

Mit dieser Erkenntnis ist das Problem zunächst auf die Firewall sehr eindeutig eingegrenzt. Also muss des Rätsels Lösung doch über die Firewall-Logs zu finden sein. Dazu wird der Paketmitschnitt mit den Logdateien verglichen. Am einfachsten kann man das erledigen, indem man die Zeitstempel von Logdatei und Paketmitschnitt übereinander legt. Ich mache das ganz simpel über die Uhrzeit, welche auch von meiner Sophos XG genutzt wird.

Dank NTP sind die Zeiten im gesamten Netzwerk synchron. Wireshark bietet die Möglichkeit, das Zeitformat unter „Ansicht -> Format der Zeitanzeige -> “ oder mit Hilfe der Tastenkombination „STRG + ALT + 2“ umzustellen.

Und jetzt wird es spannend: Zur gleichen Zeit, in der Wireshark die TCP-Resets auflistet, findet sich in der Sophos XG folgender altbekannter Fehler: „Could not associate packet to any connection“. Auch die Ports passen exakt zusammen. Damit ist ein Zusammenhang bewiesen.

Scheinbar verwirft meine Firewall Pakete. Warum? Keine Ahnung. Aber Google kann helfen. Ich habe einen Beitrag aus der Sophos Community gefunden, der Verfasser schreibt von Problemen beim Netflix-Streaming auf einem FireTV-Stick. Das klingt zumindest nach einem ähnlichen Problem. Auch die Experten in der Community können dem Verfasser nicht wirklich helfen. Dieser grenzt das Problem schließlich selbst durch Ausschlussverfahren auf den Web-Filter ein. Nun, das ist zumindest ein Versuch wert. Immerhin musste ich seinerzeit bereits eine Ausnahme für das CDN von Akamai definieren, um den FireTV-Stick ans Laufen zu bekommen. Vielleicht hat Amazon einfach das CDN geändert? Bald werde ich es wissen. Meine These wird von einzelnen Einträgen im Firewall-Log gestützt, indem das CDN von Cloudfront durch den Web-Filter geblockt wird. Vielleicht verursacht dieser Umstand in der Folge die Logfile-Einträge bei Sophos XG und die TCP-Resets in Wireshark.

Also habe ich meine Ausnahmen im Webfilter bei Sophos angepasst. Nun sind alle CDNs für den FireTV-Stick erlaubt. Zudem habe ich die IP-Kategorie und Video Hosting zu den Ausnahmen hinzugefügt, da ich noch einzelne geblockte Verbindungen im Logfile entdeckt habe.
Ist das die Lösung? Gewissheit bringt ein erneuter Paketmitschnitt: Zwar gibt es noch vereinzelte TCP-Resets, aber meine Firewall hat keine TCP-Resets mehr erzeugt. Dies lässt sich wieder am „Time to Live“-Wert erkennen. Sieht vielversprechend aus. Nun freue ich mich auf den Praxis-Test. Denn noch traue ich der Sache nicht…

Update 17. Dezember 2020

Ich sollte Recht behalten, denn leider war mein Erfolg nur von kurzer Dauer. Obwohl ich in der Firewall die oben beschriebenen Ausnahmen erstellt hatte, kam es immer wieder zu temporären Ausfällen. Auch die komplette Befreiung des FireTV-Stick von allen Restriktionen über eine eigens eingerichtete explizite Regel in der Firewall brachte keinen Erfolg. Im Fehlerfall sind in den *.pcap noch immer zahlreiche TCP-Resets und TCP-Retransmissions vorhanden. Zwar weiß ich mittlerweile, dass der FireTV-Stick die Verbindungen mit TCP-Resets beendet, sofern ein Stream vom Anwender abgebrochen wird. Dennoch habe ich das Problem mit den TCP-Resets selbst dann, wenn ich keinen einzigen Stream vorher starten konnte. Auffallen sind noch immer die hohen TCP-Retransmissions, auch wenn der Stick funktioniert.

Für mehr Analysen in Wireshark reichen meine Kenntnisse im Moment noch nicht aus. Dieses Wissen muss ich mir erst aneignen. Ein anderer Weg den ich noch verfolge? Das Ausschlussverfahren. Ich werde die einzelnen Komponenten meines Netzwerks austauschen und so versuchen, das Problem weiter einzugrenzen. Firewall, Switch, Access Points. So kann ich beweisen, ob es am WLAN liegt. Oder eben nicht.

Update 4. März 2021

Ich habe in der Zwischenzeit die Sophos XG Firewall als Komponente ausgetauscht. Testweise habe ich sie durch meine Unifi UDM Pro ersetzt. Damit funktioniert alles einwandfrei. Ich muss also davon ausgehen, dass das Problem irgendwo in der Konfiguration der Firewall zu suchen ist.

Da der FireTV-Stick nun ohne Probleme funktioniert, ist WLAN als Fehlerursache somit ausgeschlossen. Das Ausschlussverfahren hat bewiesen, dass mein WLAN nicht Teil des Problems zu sein scheint, denn an der WLAN-Konfiguration habe ich absolut nichts verändert.

Wi-Fi always gets the blame! Aber diesmal nicht! So ist es ein verbreitetes Phänomen, die Schuld erstmal beim WLAN zu suchen. Das ist sogar verständlich, denn WLAN ist oft der einzige Berührungspunkt mit Endanwendern. DNS, Firewall, RSTP, Routing? Egal, das WLAN muss eben funktionieren. WLAN-Engineers müssen daher ein überaus breites Themenfeld weit über WLAN hinaus abdecken können. Auch hier lerne ich ständig dazu.

Dennoch: Vorerst beende ich die Berichterstattung zu diesem Thema, denn Firewall-Debugging ist (zum Glück) kein Teil dieses Blogs. Schaut euch aber unbedingt folgenden Artikel zu Problemen mit Aruba WLAN und Client Match bzw. 802.11k an.