ich habe viele ESP's in meinem Netz, alle mit Arduino programmiert.
Seit ein paar Tagen habe ich ein Problem: die ESP's können nicht mehr auf den MQTT-Broker zugreifen, weil dessen Name (z.B. mqtt-broker.local) nicht mehr aufgelöst werden kann.
Leider hatte ich 2 Ereignisse in so kurzem Abstand, dass ich das Problem keinem mehr zuordnen kann, aber ich habe die Fritzbox im Verdacht:
Es gab wohl ein automatisches Update im Bereich der Arduino-IDE. Vor ein paar Tagen bekam ich (in der Folge?) eine Warnung von Windows, dass "mdns-discovery.exe" als Gefahr erkannt wurde. Reflexartig habe ich auf "ablehnen" gedrückt. Später aber gelesen, dass man das nicht tun sollte und habe die hier: https://support.arduino.cc/hc/en-us/articles/4506515275548-About-mdns-discovery erklärten Schritte befolgt. Ohne Erfolg.
Einen Tag vorher oder nachher gab es auch ein automatisches Update der Fritzbox 7590 auf FW 8.25. Ich vermute, dass das der Grund ist, denn in einem Log des MQTT-Brokers sehe ich dass der letzte Zugriff eines ESP's wenige Sekunden vor dem Update der Fritzbox erfolgte.
Ich habe das Problem im Moment so umschifft, dass ich testweise statt des Namens die IP-Adresse des MQTT-Brokers in mehreren ESP's benutze. Aber das gefällt mir nicht, und ich würde gerne verstehen was die Ursache ist.
Heute habe ich herausgefunden, dass die Namensauflösung funktioniert, wenn ich statt der .local Domain .fritz.box benutze.
(Nachtrag): Gerade habe ich noch herausgefunden, dass ich den MQTT-Broker auch alleine mit seinem Hostnamen ohne irgendeine Domain (.local oder .fritz.box) erreiche. (Für mich) Sehr merkwürdig, das erscheint mir fast wie gewollt, aber nicht dokumentiert.
Hat jemand einen Tipp, wie ich wieder zur gewohnten .local Domain komme?
Sehr, sehr unwahrscheinlich. Warum? Weil die FB noch niemals mDNS unterstützt hat. Die stellt einen ganz stinknormalen DNS-Server bereit und sonst nix.
Grundsätzlich ist mDNS ein verteilter Dienst, jeder Teilnehmer wird selbst zum Server. Anfragen erfolgen per Broadcast, antworten tun alle, die den Broadcast empfangen und meinen, die richtige Antwort zu kennen.
Es gab wohl ein automatisches Update im Bereich der Arduino-IDE.
Das wird das Problem sein. Früher(tm) hat Arduino automatisch mDNS zur Namensauflösung benutzt, wenn der angefragte Name auf die Domain .local endete. Sieht so aus, als wenn dieses schwachsinnige Verhalten jetzt endlich geändert worden wäre.
Vermutlich gibt es aber eine Konfigurationsoption, mit der das alte Verhalten wieder aktiviert werden kann. Einfach mal die Doku lesen.
Vor
ein paar Tagen bekam ich (in der Folge?) eine Warnung von Windows, dass
"mdns-discovery.exe" als Gefahr erkannt wurde.
Würde sowieso nur etwas nützen, so lange der Windows-Rechner läuft.
Heute habe ich herausgefunden, dass die Namensauflösung funktioniert,
wenn ich statt der .local Domain .fritz.box benutze.
Hier wird das normale DNS benutzt und die Antwort kommt von der Fritzbox.
Gerade habe ich noch herausgefunden, dass ich den
MQTT-Broker auch alleine mit seinem Hostnamen ohne irgendeine Domain
(.local oder .fritz.box) erreiche.
Ja. Ohne explizit angegebene Domain wird automatisch die default domain verwendet, die der DHCP-Server bei der Zuteilung des Leases an den Client gleich mit verteilt.
Hat jemand einen Tipp, wie ich wieder zur gewohnten .local Domain komme?
Wie gesagt: du mußt den Arduino-Quatsch einfach dazu bringen, für .local mDNS statt DNS zu befragen.
Ja. Ohne explizit angegebene Domain wird automatisch die default domain
verwendet, die der DHCP-Server bei der Zuteilung des Leases an den
Client gleich mit verteilt.
Früher(tm) hat Arduino automatisch mDNS zur
Namensauflösung benutzt, wenn der angefragte Name auf die Domain .local
endete. Sieht so aus, als wenn dieses schwachsinnige Verhalten jetzt
endlich geändert worden wäre.
Wie mit .local umgegangen wird, ist anscheinend "Ansichtssache".
In einem Artikel zur verwendeten mDNS library (ESPmDNS.h) steht, dass bei der Angabe eines aufzulösenden Hosts der Domainname .local "optional" sei. Das wäre ja im Widerspruch zu dem was du schreibst. DAS Verhalten von Arduino ist m.E. ohnehin nicht so einfach wiederzugeben, das hängt doch von der verwendeten lib ab, und derer gibt es einige.
Sehr, sehr unwahrscheinlich. Warum? Weil die FB noch niemals mDNS
unterstützt hat. Die stellt einen ganz stinknormalen DNS-Server bereit
und sonst nix.
Der Verdacht bleibt aber bestehen, dass die FB ihre Finger im Spiel hat, da ja ESP's die ich seit Monaten/Jahren nicht angefasst habe, plötzlich "ihren" <MQTT-Broker>.local nicht mehr finden.
Ich würde da doch mal durch die FRITZ!Box-Einstellungen schauen, ob da
irgendwas den erforderlichen Multicast blockiert.
Ich bin da schon mehrfach durch alle() Einstellungen. Am ehesten fiel mir "Aktive WLAN Geräte im Netzwerk dürfen miteinander kommunizieren" auf; das war aber zugelassen. Was könnte denn das "irgendwas" noch sein, das das mDNS behindert?
Heimnetz
Änderung Das DNS-Suffix 'fritz.box' wird in den Voreinstellungen nicht mehr an Heimnetzgeräte per DHCP verteilt. Heimnetzgeräte wiederholen fehlgeschlagene Namensanfragen nun nicht mehr automatisch mit der Endung 'fritz.box'. Das vorherige Verhalten lässt sich unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> Erweiterte Netzwerkeinstellungen -> IPv4 -> DHCP aktivieren, sofern benötigt
Verbesserung
Für die lokale Namensauflösung (per mDNS) werden unterstützt: fritzbox.local, gateway.local, box.local (nur FRITZ!Box), repeater.local, fritzrepeater.local (nur Repeater/MeshSet), sowie allgemein router.local und gateway.local
Was könnte denn das "irgendwas" noch sein, das das mDNS behindert?
Wenn man z.B. mehrere DHCP-Server betreibt, sollte man auf den IP-Bereich achten. Evtl. wird da was doppelt bei Dir vergeben? In zweifelhaften Fällen kann ein DHCP auch feste IPs zuweisen, damit z.B. der Drucker immer die gleiche hat. Das kann auch die FB.
Früher(tm) hat Arduino automatisch mDNS zur
Namensauflösung benutzt, wenn der angefragte Name auf die Domain .local
endete. Sieht so aus, als wenn dieses schwachsinnige Verhalten jetzt
endlich geändert worden wäre.
Es ist explizit und offiziell definiert, dass .local immer über mDNS aufgelöst werden muss. Das hat nichts mit Arduino zu tun, so sind die offiziellen Netzwerkstandards, an die sich alle halten (sollten).
Man kann es natürlich trotzdem absichtlich falsch machen, wir haben hier auch einen Firmenpartner, der local. als seine lokale Domänenendung in normaler unicast DNS verwendet. Aber es ist und bleibt falsch, sowas zu machen, und wird Probleme bereiten.
Diesen Versuch habe ich leider abbrechen müssen (7590).
Da geht ja gar nichts!
Einloggen nach dem Update: Da lande ich auf einer FB internen 404 Seite.
Nach erneutem Versuch ok.
Alle Seiten bauen schnarchend langsam auf.
WiFi geht gar nicht mehr: In der FB "an". Aber es gibt kein Netz mehr.
In den Einstellungen ist "Einstellungen anpassen" aktiv, aber die Einstellungen ausgegraut.
Werde zwischenzeitlich ausgeloggt (?) und lande unvermittelt auf der Login-Seite.
etc. etc. für mich ist das kaum über alpha hinaus...
Trotzdem interessant, die "Änderungen" die da drin sein sollen. Anscheinend wird ja mDNS untertstützt. Ob das jetzt neu ist wurde mir aus den bisherigen Posts nicht klar.
Wenn man z.B. mehrere DHCP-Server betreibt, sollte man auf den
IP-Bereich achten. Evtl. wird da was doppelt bei Dir vergeben? In
zweifelhaften Fällen kann ein DHCP auch feste IPs zuweisen, damit z.B.
der Drucker immer die gleiche hat. Das kann auch die FB.
Ich habe nur einen DHCP-Server, diese FB.
Die Lease Time habe ich auf 31 Tage gesetzt. Da gab es seit Jahren keine Änderungen. Trotzdem sind ein paar Infrastruktur-Geräte außerhalb des DHCP Bereichs fest zugewiesen. Da sehe ich kein Problem.
Trotzdem sind ein paar Infrastruktur-Geräte außerhalb des
DHCP Bereichs fest zugewiesen. Da sehe ich kein Problem.
Sofern Du keine VPN-Einwahl in die Fritzbox verwendest, wirst Du auch keine bekommen. Bei der VPN-Einwahl aber (egal, ob ipsec oder wireguard) wird dem sich einwählenden Client eine IP-Adresse aus dem von der Fritzbox verwalteten Bereich zugewiesen. Diese liegt, wenn der DHCP-Server aktiviert ist, oberhalb des DHCP-Adresspools, und wenn der DHCP-Server deaktiviert ist, in der Mitte des Adressraums, bei einem /24-Netz also bei .128 und aufsteigend für weitere Clients.
Wenn man also anderweitig vergebene statische IP-Adressen hat, die nahtlos an den DHCP-Adresspool anschließen, dann gibts Ärger.
Ärgerlicherweise kann man das bei der Fritzbox nicht konfigurieren.
Wenn man also anderweitig vergebene statische IP-Adressen hat, die
nahtlos an den DHCP-Adresspool anschließen, dann gibts Ärger.
Auch Blödsinn, meine FB weis davon nichts und funktioniert einfach. Der DHCP-Server vergibt immer Adressen aus seinem Pool die gerade nicht aktiv sind. Zu Überschneidungen (Adresskonflikten) kann es nur kommen, wenn im Netzwerk ein Gerät mit fest konfigurierter IP zugeschaltet wird und diese Adresse vom DHCP-Server bereits vergeben wurde.
Ich habe einem Großteil meiner Netzwerkgeräte mit fester IP versehen. Die festvergebenen IP's liegen unter- und oberhalb des DHP-Pools. Funktioniert bestens. Bei den Geräten mit DHCP habe ich bei einigen eingestellt der Server möge immer die gleiche Adresse vergeben und auch das funktioniert bestens.
Wenn der DHCP deaktiviert ist, gibt es gar kein DHCP - wie auch. In dem
Fall mußt Du allen Geräten selbst eine gültige Adresse zuweisen.
Ach. Da wäre ich nicht draufgekommen.
Die VPN-Clients bekommen eine Adresse zugewiesen, die in der Mitte des sich aus dem Subnet ergebenenden Adressraums liegt. Beim üblichen /24-Netz ist das dann 192.168.178.128 und aufsteigend.
