ubuntuusers.de

lubux schrieb:

Ist dein Server direkt mit dem Router verbunden oder via Switch?

sudo apt install iputils-arping

und versuch dann mit:

sudo arping -c 3 -I eth0 192.168.1.40

(eth0 evtl. anpassen).

Server ist direkt mit dem Router (Unifi Dream Machine Pro) verbunden.

Ergebnis arping

% sudo arping -c 3 -I en0 192.168.1.40                                                  
ARPING 192.168.1.40
60 bytes from 94:c6:91:af:e4:e7 (192.168.1.40): index=0 time=10.172 msec
60 bytes from 94:c6:91:af:e4:e7 (192.168.1.40): index=1 time=15.559 msec
60 bytes from 94:c6:91:af:e4:e7 (192.168.1.40): index=2 time=18.546 msec

--- 192.168.1.40 statistics ---
3 packets transmitted, 3 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 10.172/14.759/18.546/3.465 ms

oberalf, danke für den Link zum aktuellen Bios. Vor dem BIOS Update habe ich allerdings etwas Respekt – das möchte ich eigentlich nur machen, falls das wahrscheinlich die Ursache meines Problems behebt.

Tim3010 schrieb:

Server ist direkt mit dem Router (Unifi Dream Machine Pro) verbunden.

Ergebnis arping

% sudo arping -c 3 -I en0 192.168.1.40                                                  

OK, dann mach zukünftig den arping, wenn dein Server per ssh und per Ping (icmp) nicht erreichbar ist.

Tim3010 schrieb:

oberalf, danke für den Link zum aktuellen Bios. Vor dem BIOS Update habe ich allerdings etwas Respekt – das möchte ich eigentlich nur machen, falls das wahrscheinlich die Ursache meines Problems behebt.

Das tut überhaupt nicht weh. ☺ Du kannst ja mal in den Descriptions nachlesen, welche Fehler behoben oder Sicherheitslücken geschlossen wurden. Bei einem früheren Arbeitgeber hatten wir die NUCs immer wieder aktualisiert, das haben alle überlebt. 😉

lubux schrieb:

Tim3010 schrieb:

Server ist direkt mit dem Router (Unifi Dream Machine Pro) verbunden.

Ergebnis arping

% sudo arping -c 3 -I en0 192.168.1.40                                                  

OK, dann mach zukünftig den arping, wenn dein Server per ssh und per Ping (icmp) nicht erreichbar ist.

Eine Zeit lang lief alles problemlos. Heute Vormittag habe ich den Server neu gestartet um Updates einzuspielen, soweit auch alles ok.

Heute Abend war der Server dann wieder nicht mehr erreichbar: einloggen per ssh nicht möglich, keine Antwort auf ping, und auch keine Antwort auf arping:

ARPING 192.168.1.40
Timeout 
Timeout
Timeout
-- 192.168.1.40 statistics ---
3 packets transmitted, 0 packets received, 100% unanswered (0 extra)

Nach einem Neustart des Servers über den Power Button funktioniert jetzt temporär wieder alles normal.

Hat jemand eine Idee, wie ich das Problem eingrenzen kann?

Oberalf, danke fürs Mut machen ☺ Vielleicht wage ich mich noch ans Firmware Update. Dass mein Problem daher kommt, vermute ich allerdings nicht.

Tim3010 schrieb:

Nach einem Neustart des Servers über den Power Button funktioniert jetzt temporär wieder alles normal.

Versuch mal in der systemweiten crontab (/etc/crontab) oder gleichwertig vom Server, mit dem wirksamen Eintrag:

* *	* * *	root	/usr/bin/arping -q -c 3 -w 3 -b -f -I eno1 -s 192.168.1.40 192.168.1.1 > /dev/null 2>&1
# - - - 

(Pfad, IP-Adressen und Interface prüfen).
Danach von einem anderen Gerät (mit Linux oder gleichwertig) im W/LAN vom Server, testen mit z. B.:

sudo tcpdump -c 50 -vvveni eth0 arp and 'src host 192.168.1.40 and dst host 192.168.1.1'

(eth0 evtl. anpassen, den Rest prüfen).

Hast Du mal Tastatur+Maus+Moni angehängt, um zu sehen, ob nur das Netzwerk hängt oder der ganze Rechner? Einloggen via virtuelle Konsolen sollte in jedem Fall gehen, sofern nicht der ganze Server hängt. Dann mit Kommandozeilenbefehlen Probleme suchen: CPU überlastet? Filesystem voll? Logdateien nachsehen? Netzwerk lebt noch (aus Serversicht)?

Noch zwei weitere Beobachtungen:

Eine weitere Fehlermeldung, die ich bisher noch nicht gesehen hatte:

sudo dmesg | grep "error"
[    0.679648] BERT: [Hardware Error]: Skipped 1 error records

Außerdem haben sich docker container (node red und home assistant) jetzt vorhin neu gestartet. Der Server war aber weiterhin verfügbar (ich konnte mich per ssh einloggen), die Container haben danach auch wieder funktioniert. Warum sie sich neu gestartet haben, ist mir nicht klar.

lubux schrieb:

Tim3010 schrieb:

Nach einem Neustart des Servers über den Power Button funktioniert jetzt temporär wieder alles normal.

Versuch mal in der systemweiten crontab (/etc/crontab) oder gleichwertig vom Server, mit dem wirksamen Eintrag:

* *	* * *	root	/usr/bin/arping -q -c 3 -w 3 -b -f -I eno1 -s 192.168.1.40 192.168.1.1 > /dev/null 2>&1
# - - - 

(Pfad, IP-Adressen und Interface prüfen).
Danach von einem anderen Gerät (mit Linux oder gleichwertig) im W/LAN vom Server, testen mit z. B.:

sudo tcpdump -c 50 -vvveni eth0 arp and 'src host 192.168.1.40 and dst host 192.168.1.1'

(eth0 evtl. anpassen, den Rest prüfen).

crontab editiert (arping lag bei mir in /usr/sbin) und tcpdump auf einem Macbook ausgeführt:

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes

Mehr war im Mac Terminal allerdings nicht zu sehen. Mache ich etwas falsch? IP Adresse des Servers ist 192.168.1.40, 192.168.1.1 ist das Gateway (die Dreammachine Pro). Auf dem Server in ifconfig taucht "eno1" auf, daher meine Vermutung dass "eno1" für den crontab Eintrag auch stimmt. en0 scheint mir das Wifi Interface des MacBooks zu sein.

dirkolus schrieb:

Hast Du mal Tastatur+Maus+Moni angehängt, um zu sehen, ob nur das Netzwerk hängt oder der ganze Rechner? Einloggen via virtuelle Konsolen sollte in jedem Fall gehen, sofern nicht der ganze Server hängt. Dann mit Kommandozeilenbefehlen Probleme suchen: CPU überlastet? Filesystem voll? Logdateien nachsehen? Netzwerk lebt noch (aus Serversicht)?

Nein, das hab ich bisher noch nicht gemacht. Ich werde ein langes hdmi Kabel bestellen, um den Server an den Fernseher anzuschließen. Was sollte ich im Fehlerfall dann am besten auf dem Server anschauen, vorausgesetzt das Terminal funktioniert noch? top, ifconfig, df -h?

Tim3010 9470285

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes

Mehr war im Mac Terminal allerdings nicht zu sehen.

Du musst ca. 5 Minuten warten, bis der cronjob einige Male ausgeführt wird. Wenn der Filter ok ist, gibt es auch Ausgaben mit tcpdump.

lubux schrieb:

Tim3010 9470285

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes

Mehr war im Mac Terminal allerdings nicht zu sehen.

Du musst ca. 5 Minuten warten, bis der cronjob einige Male ausgeführt wird. Wenn der Filter ok ist, gibt es auch Ausgaben mit tcpdump.

Leider auch nach längerer Wartezeit kein Output: 0 packets captured. Kann ich das irgendwie debugen? Der Pfad zu arping stimmt, den Rest verstehe ich zu wenig um sicher zu sein, dass das so alles richtig ist.

Wie sind die Ausgaben von:

apt policy iputils-arping arping
which arping

?

$ apt policy iputils-arping arping
iputils-arping:
  Installiert:           (keine)
  Installationskandidat: 3:20240117-1build1
  Versionstabelle:
     3:20240117-1build1 500
        500 http://de.archive.ubuntu.com/ubuntu noble/main amd64 Packages
arping:
  Installiert:           2.24-1build2
  Installationskandidat: 2.24-1build2
  Versionstabelle:
 *** 2.24-1build2 500
        500 http://de.archive.ubuntu.com/ubuntu noble/universe amd64 Packages
        100 /var/lib/dpkg/status

$ which arping
/usr/sbin/arping

crontab:

# *  *  *  *  * user-name command to be executed
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6    * * 7   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6    1 * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
* *     * * *   root    /usr/sbin/arping -q -c 3 -w 3 -b -f -I eno1 -s 192.168.1.40 192.168.1.1 > /dev/null 2>&1
#
~

und das auf dem Macbook ausgeführte Command

sudo tcpdump -c 50 -vvveni en0 arp and 'src host 192.168.1.40 and dst host 192.168.1.1'

Ich glaube es funktioniert jetzt: ich habe arping deinstalliert und dafür die iputils-arping installiert (und in crontab den Pfad auf /usr/bin/arping entsprechend geändert).

Ausgabe auf dem Macbook

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
15:37:01.479340 94:c6:91:af:e4:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.40, length 46
15:38:01.693074 94:c6:91:af:e4:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.40, length 46
15:39:01.430371 94:c6:91:af:e4:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.40, length 46

Hilft diese Ausgabe etwas? Mich wundert der Teil mit ff:ff:ff:ff:ff:ff etwas, sollte da nicht die MAC Adresse des Gateways auf 192.168.1.1 stehen?

Tim3010 schrieb:

Ich glaube es funktioniert jetzt: ich habe arping deinstalliert und dafür die iputils-arping installiert

Der Hinweis (siehe oben) war ja auch, iputils-arping zu installieren.

Hilft diese Ausgabe etwas? Mich wundert der Teil mit ff:ff:ff:ff:ff:ff etwas, sollte da nicht die MAC Adresse des Gateways auf 192.168.1.1 stehen?

Ja, ist ok so. Der 1. arp-request ist ein broadcast und geht an diese ether-Adresse. Wenn der arp-request an die MAC-Adresse vom Gateway gerichtet wäre, würdest du den arp-request mit tcpdump, auf deinem Mac nicht sehen können. Dann müsstest du auf deinem Server einen gratuitous arping (via cronjob) senden.

Danke für die Erklärung und Deine Hilfe! Heißt dann hier ist erstmal kein Fehler zu erkennen.

Bleibt Monitor und Tastatur anschließen wenn das Problem wieder auftritt, oder könnte ich sonst noch etwas prüfen?

Tim3010 schrieb:

…. wenn das Problem wieder auftritt, oder könnte ich sonst noch etwas prüfen?

Wenn das Problem wieder auftritt, schaust du mit tcpdump auf deinem Mac, ob der Server minütlich den arp-request sendet bzw. gesnifft wird.