Wackel-Bonjour

Das hat mich heute auch Zeit gekostet.

Heute Fehler eingekreist.

Ich habe doch hier einen Huawei Glasfaserroute, der zwar seine Sache an sich gut macht, aber nur die Grundfunktionen liefert. So hat das Ding zwar einen DHCP-Server, natürlich, sonst könnten viele heutige Geräte ja nicht mehr funktionieren, führt aber – anscheinend – keine eigene lokale Domain, in die sie die Rechner einträgt, wie viele andere Router (z. B. Fritzbox ) das machen. Es ist daher nicht direkt über den Router möglich, dass die Rechner sich untereinander finden. Was in typischer Familienmanier auch nicht erforderlich ist. (IPv6 habe ich mir ja schon mit viel Überredungsgeschick freischalten lassen müssen, weil das normalerweise abgeschaltet wird, weil man es hier nicht braucht und es nur zu Konfiguriations- und Routingproblemen führt.)

Nun ist das aber kein Problem, es gibt da eine Lösung. Das Protokoll heißt Bonjour, der passende Server dafür unter Linux heißt Avahi, und das ist genau dafür gebaut, genau dieses Problem zu lösen. Rechner finden sich (und Dienste) über Multicast-DNS. Die Rechner fragen sich per Multicast einfach gegenseitig alle. Das hat zwar auch Sicherheitsprobleme, aber solange man in seinem eigenen Netz bleibt und authentifizierende Protokolle verwnedet, ist das soweit in Ordnung.

Geht. Geht nicht. Geht. Geht nicht…

Untersucht, warum es manchmal geht, aber in bestimmten Kombinationen vom Notebook zum Server nicht geht.

Lösung erster Schritt: Das Problem tritt auf, wenn ein Rechner im WLAN nach einem Rechner fragt, der per Ethernet am Router angeschlossen ist.

Zweite Erkenntnis:

Ich hatte zwei Amazon-Alexa-Geräte im WLAN. Die haben die üble Angewohnheit, auf multicast-dns-Anfragen, und zwar auch dann, wenn man nicht nach ihnen fragt, immer mit einer Antwort zu antworten, in denen sie einen aus ihrer IP-Adresse zusammengesetzen Namen per mdns mitteilen. Das ist überflüssig und ziemlih nutzlos, wäre im Allgemeinen aber nicht schädlich, weil die Software das kann, dass sie Antworten, nach denen sie nicht gefragt hat, entweder verwirft oder bei der Gelegenheit auch mit aufnimmt.

Nur: Der Router reicht die Antwortpakete in diesem Fall nicht vom Ethernet an das WLAN weiter. Ich sehe auf dem Notebook im WLAN zwar die Antwort der Alexa-Geräte auf eine Frage, die ich nicht gestellt habe, aber nicht die Antwort des Servers. Offenbar ist der Huawei-Router nicht in der Lage, unter dieser Konstellation noch die Antwort des Servers ins WLAN weiterzuleiten, offenbar wird das Paket verworfen.

Schalte ich aber die beiden Alexa-Geräte aus, dass die also keine Antworten direkt ins WLAN mehr schicken können, dann funktioniert es, dann reicht der Huawei-Router auch die Antwort des Servers weiter.

Grrr!

Die Frage ist nun, wer eigentlich den Fehler macht und gegen das Protokoll verstößt: Der Huawei-Router, weil er unter bestimmten Bedingungen Pakete verwirft (was ein Router im Prinzip darf, aber nicht systematisch), oder die Alexa-Geräte, weil sie Antworten rausplärren, nach denen nicht gefragt wurde.

Muss mal noch etwas debuggen und untersuchen, aber es ist ärgerlich, dass man für so etwas Zeit verbrät.

Würde mich mal interessieren, was die bei Amazon sich dabei gedacht haben, das so zu implementieren.

Da muss ich wohl noch ein bisschen debuggen, denn so ganz klar ist mir das nicht, ob das wie früher der Avahi-Server beantworten soll, oder ob das nun der resolved von systemd machen soll (vgl. man resolved.conf ).

*seufz*

Eigentlich hätte ich Wichtigeres zu tun.