Fehlermeldung Logfile UPnP Error Invalid Action - nach Fritzbox-Neustart

[swsmily]

Der Raspi arbeitet vermutlich mit fester IPv4?
Wie lange braucht denn die FritzBox, dass sie erst nach 10 Minuten auf der internen IP erreicht wird?

Der Anschluss hat eine feste öffentliche IP. Diese ist nach ca 4 bis 5 Minuten wieder erreichbar. Wenige Sekunden später ist auch das VPN wieder aufgebaut und ich kann auf alles zugreifen.
Der Raspi nutzt wie alle Geräte DHCP, aber ihm ist seine IP in der Fritzbox fest zugeordnet.   

ist das attribut dnsServer im device global gesetzt?

Ja das ist gesetzt

Wichtiger Aspekt.
Ist aber doch bei
Code Auswählen Erweitern

Code Auswählen Erweitern

define FritzBox FRITZBOX xxx.xxx.xxx.xxxfür die FritzBox sekundär,oder nicht?

Das verstehe ich nicht? xxx.xxx.xxx.xxx ist nur "geschwärzt", dort steht natürlich die IP-Adresse der Fritzbox.

[RalfRog]

Das verstehe ich nicht? xxx.xxx.xxx.xxx ist nur "geschwärzt", dort steht natürlich die IP-Adresse der Fritzbox.

Ja eben, da die FritzBox per IP definiert ist sollte DNS keine Rolle spielen.

Bin jetzt nicht der Netzwerk Profi und mag falsch liegen:
wenn aber der Raspi per DHCP eine IP bekommt nehme ich an, dass zum Zeitpunkt der gezeigten LogEinträge das Netzwerksinterface des Raspi korrekt läuft und oben ist.
Damit ist die Box LAN-seitig auch oben (interne IP und DHCP), sie hat ja schließlich schon die IP's verteilt.
Dann ist " 500 Can't connect to xxx.xxx.xxx.xxx:80 (Network is unreachable)" in den Log Meldungen merkwürdig (an der Stelle weiß ich allerdings nicht wie die Meldung aussieht falls der Raspi noch keine IP hat) .

Oder gibt's im Syslog des Raspi nach "2023.07.29 22:25" noch Meldungen vom Netzwerksinterface, dass es noch nicht fertig konfiguriert war.

[swsmily]

Dann ist " 500 Can't connect to xxx.xxx.xxx.xxx:80 (Network is unreachable)" in den Log Meldungen merkwürdig.

Das kommt denke ich davon, dass ich den Raspi rebootet habe und direkt nach dem "sudo reboot" die Steckdose, an der die Fritzbox hängt abgeschaltet habe. Das ist für mich remote die einzige Möglichkeit einen "Stromausfall", bzw Arbeiten wo Strom vor Ort durch Umbaumaßnahmen abgeschaltet wird, zu simulieren.

Der Raspi ist natürlich schneller hochgefahren als die Fritzbox, damit ist für den Raspi das Netzwerk erstmal nicht erreichbar, bis die Fritzbox wieder arbeitet.

Dass es nun 10 Minuten dauert, bis FHEM die Fritzbox als die Fritzbox erkennt, die sie tatsächlich ist, stört mich nicht. Vorher hatte ich nach so einem Fall jede Minute Fehlermeldungen im Logfile, die sind mit der hier angehängen Beta weg. Damit ist für mich zumindest das Problem gelöst, wofür ich sehr dankbar bin!

[RalfRog]

Na dann passt es ja und statt Strom aus besteht die Möglichkeit "set Fritzbox reboot".

Für mich muss ich mal ausprobieren ob die Fehlermeldung von Linux auch "Network unreachable" lautet wenn das Interface noch keine IP hat. Erwarten würde ich ne andere Meldung.

[RalfRog]

Der Erkenntnisgewinn am Testsystem (mit Modul VERSION 07.50.17f) war jetzt nicht so überragend.

Meine 7590 verteilt auch per DHCP die IP's - immer die Gleiche an den Raspi. Zum Test hing der Pi1 am Switch ohne Verbindung zur Box.
 

• Lt. dmesg meldet der Kernel ca. 35 Sekunden nach dem Neustart "eth0 link up" und weitere 10 Sekunden später hat sich der Raspi aus dem 169er-Pool selber eine IPv4 vergeben, da es auf DHCP-Anfrage keine IP gab.
• Ca. 250 Sekunden danach war FHEM aktiv (mit IP 169.254.190.240)
• im FHEM Log landet dann "500 Can't connect to 11.12.13.1:80 (No route to host)", klingt logisch

Die Meldung "500 Can't connect to 11.12.13.1:80 (Network is unreachable)" hatte ich kurz vorher bei einem versehentlichen "shutdown -r now" wo alles noch korrekt verbunden war.

FHEM meldet "Server started with 28 defined entities (fhem.pl:27410/2023-04-07 perl:5.032001 os:linux user:fhem pid:699)" und sowohl das Shelly- als auch das Fritzbox-Modul versuchen direkt schon die Devices zu erreichen. Beide Module melden zunächst "Network is unreachable" - als wären noch nicht alle nötigen PERL Module (? Bereich Netzwerk/HTTP) wirklich 100% up.

Schluss damit... ist eher Kaffeesatz lesen und bringt nix solange mir nicht klar ist aus welchem Perl-Modul/Funktion die Meldung kommt. Außerdem versuchen die Module ja die Devices erneut zu erreichen.