Fehlercode 0.60 bei Prime Video auf Google Chromecast mit Android-TV

Seit etwas mehr als einer Woche plagte mich der Fehlercode 0.60 bei der "Prime Video"-App auf dem Google Chromecast mit Android TV – ich finde es ja auch furchtbar, das so auszuschreiben, aber das Gerät heißt nun mal so. Da ich meine Lösung letztendlich über ein Apple-TV-Support-Forum fand, wird das aber vermutlich auf verschiedenen Geräten von Roku, Amazon und Herstellern von Smart-TVs ähnlich sein.

Auf die falsche Fährte führte mich, dass am 2024-01-24 ein Update der App stattgefunden hat, was dann vermutlich in den ein, zwei Tagen danach auch auf meinem Chromecast landete. Während meiner Recherche habe ich mich zu sehr auf diese zeitliche Koinzidenz eingeschossen. Tatsächlich lag die Ursache aber in der Aktivierung unserer Glasfaser am 2024-01-25 und vermutlich am Kurzurlaub meiner Familie am 2024-02-03 für ein paar Tage.

Die Glasfaser-Aktivierung war schuld, weil damit erstmalig IPv6 Einzug hielt bei uns. Vorher befand sich das Heimnetz in einem Zustand von "vielleicht funktioniert das ja so". Ich konnte ja nichts belastbar testen, ich konnte keine Erfahrungen sammeln. Hätte ich nicht zu viele Eigenheiten im Heimnetz, wäre das vielleicht auch nie aufgetreten, wer weiß?

Durch IPv6 über die Glasfaser hat mein Netz jetzt jedenfalls auch endlich ein IPv6-Präfix erhalten. Und ich war super erstaunt, dass das praktisch sofort alle Geräte erreichte, die sich dann auch selbst konfiguriert hatten. Für mich ein Rätsel war aber immer noch, wie die Geräte eigentlich herauskriegen, wo das Gateway liegt und wie sie Namen auflösen sollen. Das sollte mir hierbei noch auf die Füße fallen.

Im Nachhinein kann ich mir nicht erklären, warum das nicht sofort aufgefallen ist. Vielleicht haben wir bei Amazon einfach nichts geschaut für ein paar Tage. Oder ich habe das als Fehler auf Amazons Seite betrachtet, denn alle anderen Streamingdienste liefen ja ohne Probleme. Ja, die App "Prime Video" auf dem Google Chromecast mit Android TV macht irgendwas eigenes, und sie macht das nicht auf anderen Android-Geräten – auf meinem Tablet wie auch auf dem Handy konnte ich sie normal benutzen.

Der Kurzurlaub meiner Familie wiederum war dahingehend daran beteiligt, dass ich währenddessen am NAS gearbeitet hatte, wo ich einen dnsmasq in einem systemd-nspawn-Container betreibe, der für DNS und DHCP im Heimnetz zuständig ist. Nach viel hin und her beschloss ich am Ende, um zumindest einen Teil des Umzugs durchzuführen, den alten Container auf dem neuen NAS in Betrieb zu nehmen. Für niemanden überraschend außer mich, der schlicht nicht dran gedacht hat, hat der Container dort natürlich eine neue IPv6 für sich erzeugt, so dass der DNS-Server-Eintrag in den IPv6-Netzwerkeinstellungen der Fritzbox natürlich falsch war. War er vorher vermutlich auch schon, denn es hatte ja schon vorher nicht funktioniert.

Jetzt habe ich auch ein paar Tage Urlaub und habe mich heute früh mal dran gesetzt. Der Forumsbeitrag erwähnte IPv6, und da ich das noch nicht weiter verfolgt hatte, dachte ich mir, dass ich das ja mal machen könnte. Stück für Stück habe ich dann meine Konfiguration im Heimnetz mal abgeklopft.

Die resolv.conf meines Containers war noch auf die alte IP eingerichtet.

Meine Datei für Namensauflösungs-Overrides warf immer Fehler.

Feb 08 09:34:22 lan-basics1 systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Feb 08 09:34:22 lan-basics1 dnsmasq[4698]: bad option at line 1 of /etc/dnsmasq.d/override.hosts
Feb 08 09:34:22 lan-basics1 dnsmasq[4698]: FAILED to start up
Feb 08 09:34:22 lan-basics1 systemd[1]: dnsmasq.service: Control process exited, code=exited, status=1/FAILURE
Feb 08 09:34:22 lan-basics1 systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Feb 08 09:34:22 lan-basics1 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.

Hintergrund: Auch wenn in der /etc/dnsmasq.conf steht:

conf-dir=/etc/dnsmasq.d,*.conf

so steht in der /etc/default/dnsmasq dummerweise:

CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

In der /etc/init.d/dnsmasq wird die Default-Datei dann gesourcet und CONFIG_DIR auf der Kommandozeile übergeben, womit es die Option in dnsmasq.conf überschreibt, falls die Datei dann überhaupt noch ausgewertet wird. Das hat jedenfalls dazu geführt, dass alle Dateien in /etc/dnsmasq.d eingebunden wurden, die nicht auf .dpkg-dist, dpkg-old oder dpkg-new endeten. Ich habe den Eintrag in der Default-Datei entsprechend geändert, dass er dem in der Konfigurationsdatei entspricht.

Ich vermute, die Debian-Maintainer hatten das irgendwann in der Vergangenheit aus guten Gründen so gehandhabt, aber dann nicht mitbekommen, dass die Upstream-Konfigurationsdatei das bereits erledigt, was die Maintainer erzielen wollten. Ich werde das auch mal melden müssen. Die Korrektur hat jetzt jedenfalls dazu geführt, dass meine ausgelagerten Einstellungen für DNS-Server –google.dns und quad9.dns– nicht mehr beide gleichzeitig eingebunden werden. War zwar vorher kein bemerkbares Problem, aber ich erinnere mich, dass ich zurück auf Google musste, weil Quad9 irgendeinen Blödsinn gemacht hat (oder auch nix gemacht hat).

Ich finde solche Probleme bei Konfigurationsdateien ja doch sehr ärgerlich. Ich möchte gerne wissen, welche Dateien die Laufzeit-Konfiguration enthalten. Ich möchte Kontrolle darüber haben. Ich will nicht so überrascht werden.

Auf der anderen Seite, beim Chromecast, konnte ich zumindest feststellen, dass die App funktionierte, wenn ich die Netzwerkkonfiguration von "DHCP" auf "statisch" änderte.

Trivia: Ändert man das, werden die einzelnen Optionen nicht mit den letzten DHCP-Werten befüllt, sondern mit generischen Werten aus dem 192.168.1.1/24-Netz. Und die Eingabe über die Fernbedienung ist nicht sonderlich komfortabel.. Immerhin müssen nur Adresse, Subnetzlänge und Gateway eingegeben werden. Bei den DNS-Servern habe ich schlicht die Vorgaben (Google-DNS) verwendet.

Damit ging es also, was mir die Vermutung nahelegte, dass irgendwas bei der DHCP-Konfiguration schief lief. Aber mehr als die IP-Adressen kann ich der Oberfläche des Chromecast nicht entlocken. Und irgendwie funktionierte ja die Konfiguration. Ich habe wieder einmal in die DHCP-Einstellungen von dnsmasq geschaut, und wieder hatte ich vergessen, dass IPv6 anders konfiguriert wird. Mein Router meldet den IPv6-Clients, welchen DNS-Server sie verwenden sollen. Und da fiel mir dann auf, dass da ein falscher Wert steht. Schwupps ausgetauscht gegen die aktuelle IPv6-Adresse des lan-basics-Containers, und schon läuft es.

Hilfreich zum Überprüfen (Quelle: How can I view IPv6 router advertisements that are being received by my computer for diagnostic purposes?) :

tcpdump -n -i wlp2s0 icmp6
tcpdump -n -i wlp2s0 icmp6 and ip6[40] == 134
radvdump

Interessanter Nebeneffekt: Ich hatte seit Monaten das Gefühl, dass mein Tablet beim Aufruf einer noch nicht cachierten Website eine unangenehm lange Denkpause einlegt. Ich hatte DNS im Verdacht, aber ich fand nichts. Ich denke, das geht jetzt auch flotter. Vermutlich hat auch das Tablet erst einmal DNS per IPv6 aufzulösen versucht, und wenn keine Antwort kam, hat es IPv4 probiert. Das scheint die "Prime Video"-App nicht zu machen.

Mir bleibt nur noch die Frage offen, wie stabil die Selbstkonfiguration bei IPv6 ist. Ich habe für den lan-basics-Container folgendes gesetzt:

IPv6LinkLocalAddressGenerationMode=eui64

Nach dem Wälzen der man-Page (ist schon ein paar Monate her) scheint mir das die einzige Einstellung zu sein, die keine Konflikte erzeugen kann und reproduzierbar die gleiche IPv6-Adresse erzeugt. Aber ist das so?