Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[OliverIO]

@Blackmyth said in ioBroker funktioniert täglich nicht mehr:

ay: connect ENETUNREACH 192.168.0.60:80 - Local (0.0.0.0:0)

sieht nach verlorener Netzwerkverbindung aus.
Erst kann er ein Gerät in deinem lokalen netzwerk nicht erreichen 192.168.0.60
Dann melden sich die anderen Adapter, ebenfalls, dass sie die Gegenseiten nicht erreichen können (Spotify, roomba, alexa, etc.)

Schau mal in das syslog des Rechners (wenn es Linux ist) um diese Zeit herum.
Alternativ bei Windows in das Ereignisprotokoll.
Ist der Rechner per WLAN angebunden? Wird das unterbrochen?
Die Hue-Lampen funktionieren wahrscheinlich deswegen noch, weil die nicht per Netzwerk, sondern per Bluetooth angesteuert werden.
Ist das immer die gleiche Zeit?
Kommt ein anderes Gerät mit gleicher IP ins Netz?

[Blackmyth]

@OliverIO
Danke für die Rückmeldung.

Die 192.168.0.60 ist die Phillips Hue Bridge.

Kannst du mir sagen wo ich das Logfile unter Linux finde ?
Der Pi ist per Lan Kabel angeschlossen, alle Netzwerkgeräte bekommen Ihre IP per DHCP zugewiesen.

Die Hue Leuchten werden per Netzwerk angesprochen.
Zeit des Fehlers ist leider immer unterschiedlich.

Eigentlich sollte kein anderes Gerät mit der gleichen IP im Netzwerk sein, da alles per DHCP gesteuert wird.
In der FritzBox erscheint mit der 192.168.0.60 auch nur die Hue Bridge

[OliverIO]

Die logs in Linux liegen im Verzeichnis

/var/log/

Das aktuelle also unter /var/log/syslog

Je nach Archivierungsregel hängt noch eine Nummer dran oder es ist komprimiert (meist .gz)

je nach Berechtigung muss du mit adminrechten drauf schauen, also sudo vor dem befehl.

[OliverIO]

@Blackmyth
das mit doppelter IP war nur ne Vermutung weil es ein Grund sein kann, warum ein gerät aus dem Netzwerk fällt. ob die Fritzbox den hostname schnell genug mitbekommt, ist auch kein verlässliches anzeichen.
Den zeitpunkt kannst du ja aus dem iobroker log entnehmen.
Ich sehe da ab 2020-01-20 20:20:17.466 haben die Probleme angefangen.
ich denke du wirt in deinem log jetzt nicht tausende von Meldungen um diesen Zeitpunkt herum drin haben.
wie gesagt, das syslog wird idR jeden Tag oder nach jedem Neustart neu angelegt und die alten werden eine gewisse Zeit archiviert.

[Blackmyth]

@OliverIO
Leider bekomme ich auf die schnelle das Logfile nicht gespeichert.
Hier aber ein kleiner Auszug, was mir um die Uhrzeit aufgefallen ist und mir auch nach dem Problem aussieht.

Die 192.168.0.68 ist die IP meines ioBroker´s
Hast du dazu eine Idee ?

Falls du doch das ganze Log benötigst muss ich mich schlau machen wie es von Linux auf den Mac bekomme.

an 20 20:17:01 PI-IoB CRON[15850]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: hardware address f8:04:2e:16:1e:fa claims 192.168.0.68
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: hardware address f8:04:2e:16:1e:fa claims 192.168.0.68
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: 10 second defence failed for 192.168.0.68
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: deleting route to 192.168.0.0/24
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: deleting default route via 192.168.0.1
Jan 20 20:20:17 PI-IoB avahi-daemon[331]: Withdrawing address record for 192.168.0.68 on eth0.
Jan 20 20:20:17 PI-IoB avahi-daemon[331]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.68.
Jan 20 20:20:17 PI-IoB avahi-daemon[331]: Interface eth0.IPv4 no longer relevant for mDNS.
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: rebinding lease of 192.168.0.68
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: probing address 192.168.0.68/24
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: hardware address f8:04:2e:16:1e:fa claims 192.168.0.68
Jan 20 20:20:17 PI-IoB dhcpcd[577]: eth0: DAD detected 192.168.0.68
Jan 20 20:20:18 PI-IoB dhcpcd[577]: eth0: soliciting a DHCP lease
Jan 20 20:20:18 PI-IoB dhcpcd[577]: eth0: offered 192.168.0.69 from 192.168.0.1
Jan 20 20:20:18 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:22 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:23 PI-IoB dhcpcd[577]: eth0: probing for an IPv4LL address
Jan 20 20:20:26 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:28 PI-IoB dhcpcd[577]: eth0: using IPv4LL address 169.254.119.10
Jan 20 20:20:28 PI-IoB dhcpcd[577]: eth0: adding route to 169.254.0.0/16
Jan 20 20:20:28 PI-IoB dhcpcd[577]: eth0: adding default route
Jan 20 20:20:28 PI-IoB avahi-daemon[331]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.119.10.
Jan 20 20:20:28 PI-IoB avahi-daemon[331]: New relevant interface eth0.IPv4 for mDNS.
Jan 20 20:20:28 PI-IoB avahi-daemon[331]: Registering new address record for 169.254.119.10 on eth0.IPv4.
Jan 20 20:20:29 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:32 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:37 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:42 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:46 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:49 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:53 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:20:57 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:21:00 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:21:05 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:21:08 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:21:13 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1
Jan 20 20:21:17 PI-IoB dhcpcd[577]: eth0: reject NAK via 192.168.0.1

[OliverIO]

@Blackmyth said in ioBroker funktioniert täglich nicht mehr:

f8:04:2e:16:1e:fa

ich denk da war ich mit meiner vermutung gar nicht so schlecht.

das Gerät mit der Mac f8:04:2e:16:1e:fa greift sich die IP-Adresse 192.168.0.68
dann meldet sich dein pi aus dem netzwerk ab (routen löschen, ip-adresse auf dem gerät unbgültig machen)
dann folgen avahi und meldet sich auch ab.
dann versucht der pi die ip adresse wieder zu bekommen und stellt fest,
das diese schon bei einem anderen gerät ist (DAD detected)
dann bietet dein dhcp eine andere ip an (offered 192.168.0.69 from 192.168.0.1)
die wird aber abgelehnt (reject NAK via 192.168.0.1)
was danach kommt, ist eine notfall ip 169.254.119.10 die aber nur auf dem lokalen gerät gültig ist

wenn ich nach der MAC suche kommt, das das zu einem samsung gerät gehört
https://www.macvendorlookup.com/

Hast du auf dem Pi eine feste IP konfiguriert? Was grundsätzlich für Infrastrukturkomponenten im netzt auch richtig ist.
Allerdings musst du dem DHCP-Server sagen, das er die nicht vergeben darf.
DHCP prüft nicht, ob ein Gerät dies schon als feste IP konfiguriert hat.
Schau im router bei DHCP nach, welchen IP-Bereich er vergeben kann.
Mein DHCP vergibt dynamische IPs erst ab 100. Alles drunter kann ich statisch konfigurieren (bis auf die 1)
Schau auch mal im Router, ob du dort IP-Adressen schon fest auf Geräte vergeben hast. Das geht bei DHCP auch, das er dem gleichen Gerät (MAC-ID) immer die gleiche IP gibt.

[Homoran]

@Blackmyth sagte in ioBroker funktioniert täglich nicht mehr:

Jan 20 20:20:18 PI-IoB dhcpcd[577]: eth0: soliciting a DHCP lease

Hast du keine IP-Bindung in dem Router eingestellt?

Wie lange hält der Lease?

[Blackmyth]

@Homoran
Steht beides auf den Standard Einstellungen, hatte ich nie was geändert.

[Blackmyth]

@OliverIO
Hört sich nach der Lösung an. Die Mac Adresse existiert aber komischerweise nicht.
Ein Samsung Gerät habe ich aber.

Werde morgen den DHCP mal korrekt einstellen, der hat nämlich keinen Bereich hinterlegt. IoBroker, NAS usw haben in der Fritz Box fest hinterlegte Adressen.
Werde dann nochmal berichten, vielen vielen Dank für die Hilfe schon mal.

[Blackmyth]

Kurze Rückmeldung: Problem ist nach dem anpassen des DHCP Bereichs behoben.
Vielen Dank euch allen für die Hilfe