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

[harrym]

@Homoran Das is dann aber es DAU problem g

EDIT: Aber normal macht ja da de Fritte eine Blockade bzw. ne Meldung ???

[mguenther]

in der /etc/dhcpcd.conf habe ich folgendes eingetragen:

[harrym]

@mguenther tja .... statisch definiert im linux .... mach das weg ... rein via dhcp ... und eben alles via fritte vergeben.

[mguenther]

@harrym
aber damit hatte ich dann irgendwann die Probleme - war ja auf der Suche nach ner Lösung.

[harrym]

@mguenther why ? die fritte ist doch selbsterklärend und vergibt von sich aus eine ip nur einmal .... du kannst die auch auf fix ändern je client ....

[mguenther]

@hans_999 sagte in Pi verliert LAN - nicht erreichbar:

undervoltage

ich habe die Datei mit Nano geöffnet und nach undervoltage gesucht, aber nix gefunden. Zumindest aktuell nicht.

[harrym]

@mguenther tac /var/log/syslog | grep -i undervoltage

[mguenther]

@harrym sagte in Pi verliert LAN - nicht erreichbar:

tac /var/log/syslog | grep -i undervoltage

[harrym]

@mguenther haste unter /var/log eventuell ein paar syslog.gz ?? ls -la /var/log/syslog*

[harrym]

oder loggt der PI des voltage echt im kernel log?????

[mguenther]

@harrym
das kann ich dir nicht sagen, aber ja, es gibt mehrere Syslogs:

[harrym]

@mguenther dann mach mal ein tac /var/log/syslog.1 | grep -i undervoltage

[mguenther]

@harrym sagte in Pi verliert LAN - nicht erreichbar:

tac /var/log/syslog.1 | grep -i undervoltage

nix - wie vorher

[OliverIO]

in einem guten Netzwerkdesign sollten Infrastruktur relevante Geräte (router,nas) immer feste ips haben. idealerweise im gerät fest definiert, so dass ich keine weitere Abhängigkeit zu anderen geräten oder services habe (DHCP).

Bei iobroker kann man natürlich diskutieren, ob der Infrastruktur relevant ist.
ich habe aber auf dem Gerät eine feste IP definiert, aus der ip-range, die ich für diese geräte im dhcp ausgeklammert habe. iobroker ist auf einem intel-nuc mit noch anderen services.
so sind diese auch ansprechbar, falls der dhcp-dienst mal nicht funktioniert.

[harrym]

@mguenther mach mal tac /var/log/kernel.log | grep -i undervoltage ... und dann es geiche nochmal mit kernel.1

[harrym]

@OliverIO sagte in Pi verliert LAN - nicht erreichbar:

in einem guten Netzwerkdesign sollten Infrastruktur relevante Geräte (router,nas) immer feste ips haben. idealerweise im gerät fest definiert, so dass ich keine weitere Abhängigkeit zu anderen geräten oder services habe (DHCP).

Bei iobroker kann man natürlich diskutieren, ob der Infrastruktur relevant ist.
ich habe aber auf dem Gerät eine feste IP definiert, aus der ip-range, die ich für diese geräte im dhcp ausgeklammert habe. iobroker ist auf einem intel-nuc mit noch anderen services.
so sind diese auch ansprechbar, falls der dhcp-dienst mal nicht funktioniert.

wenn der dhcp dienst mal nicht funktioniert ... haste so und so ein problem ;) wichtige dinge bei mir haben auch ne fixe ip ... ohne dhcp ...

[hans_999]

Auf meinem Pi finde ich das vor allem in /var/log/kern.log. Es gibt aber auch (aber weniger) Einträge im Syslog
Aber wenn man vollautomatisiert suchen lässt, hilft es sehr, wenn das Suchpattern korrekt ist.
@hans_999 said in Pi verliert LAN - nicht erreichbar:

Schau doch einmal in die Meldungen des BeSy unter /var/log/kern.log und prüfe, ob dort Meldungen der Art
Under-voltage detected! (0x00050005)

zu finden sind.

"untervoltage" scheitert als Suchstring natürlich gnadenlos.

[harrym]

@hans_999 sagte in Pi verliert LAN - nicht erreichbar:

Under-voltage detected! (0x00050005)

guter einwand ! ich hab leider keinen rp :/

[mguenther]

@harrym sagte in Pi verliert LAN - nicht erreichbar:

tac /var/log/kernel.log | grep -i undervoltage

ihr habt mich gerade verloren...

[hans_999]

@mguenther said in Pi verliert LAN - nicht erreichbar:

ihr habt mich gerade verloren...

Ich schrub gerade, dass die Meldung

"Under-voltage detected! (0x00050005)"

heißt. Also nach "Under-voltage" suchen.
Des weiteren sind die Logeinträge bei mir auf einem Pi in der Datei /var/log/kern.log zu finden (nicht kernel.log !).

Bei mir klappt's mit der Suche mit

tac /var/log/kern.log | grep -i under

relativ stressfrei. Ich bin nämlich auch noch schreibfaul :-)