Hi zusammen,
"Glücklicherweise" ist es eben schon wieder passiert. Der PC mit der IP-Endung 102 ist aus dem Netzwerk gedropt. Ich habe einen Screenshot der Netzwerkverbindungen aus der FB dem Anhang hinzugefügt. Dort sind gleich beide eingangs erwähnten Probleme vorhanden. Unter "Ungenutzte Verbindungen" sind zum einen der 102er und zum anderen der 240er gelistet. Beide PCs sind jedoch mit dem Router verbunden.
Auf den 204er trifft das "Problem 1" zu, dass ich in meinem ersten Post beschrieben hatte. Auf den 102er das "Problem 2". D.h. der 204er ist im Netzwerk voll erreichbar und müsste eigentlich in "Aktive Verbindungen" gelistet werden. Dennoch stört mich dieses Problem eher weniger. Viel kritischer ist dagegen der 102er. Dieser wurde aus dem Netzwerk gekickt oder hat es verlassen. Fakt ist der Webserver der auf diesem Server lief, ist nicht erreichbar. Und SSH oder FTP Logins gehen nicht.
–-
encbladexp schrieb:
Können sich die Kisten noch untereinander pingen wenn der Fehler auftritt? Was sagt im Fehlerfall der Befehl ip -s a
und ethtool eno1
(halt passend für dein Interface anpassen).
mfg Stefan
wenn ich ping 192.168.178.102 starte, erhalte ich
PING 192.168.178.102 (192.168.178.102) 56(84) bytes of data.
64 bytes from 192.168.178.102: icmp_seq=1 ttl=64 time=0.096 ms
64 bytes from 192.168.178.102: icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from 192.168.178.102: icmp_seq=3 ttl=64 time=0.065 ms
64 bytes from 192.168.178.102: icmp_seq=4 ttl=64 time=0.063 ms
64 bytes from 192.168.178.102: icmp_seq=5 ttl=64 time=0.065 ms
64 bytes from 192.168.178.102: icmp_seq=6 ttl=64 time=0.063 ms
folglich per ping erreichbar
Beim Versuch mich via SSH oder FTP braucht einzuloggen, kommt keinerlei Feedback oder Fehlermeldung und der Login bleibt erfolglos. Hier der Output für ssh -v mein_benutzer@192.168.178.102
$ ssh -v mein_benutzer@192.168.178.102
OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017
debug1: Connecting to 192.168.178.102 [192.168.178.102] port 22.
debug1: Connection established.
debug1: identity file /home/mein_benutzer/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
danach kommt keine Meldung und der SSH Client scheint abzustürzen bzw. gibt keine Meldungen mehr aus.
Beim Login auf bspw. den 101er hingegen folgen noch weitere Meldungen:
$ ssh -v mein_benutzer@192.168.178.101
OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017
debug1: Connecting to 192.168.178.101 [192.168.178.101] port 22.
debug1: Connection established.
debug1: identity file /home/mein_benutzer/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/mein_benutzer/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.178.101 as 'mein_benutzer'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
...
und das Ganze läuft durch bis zum erfolgreichen Login.
–-
elektronenblitz63 schrieb:
Ändere den Adresspool der FB von 192.168.178.20 - 192.168.178.80
in diesem Bereich werden die Adressen über DHCP vergeben
ab 192.168.178.2 - 192.168.178.19 und 192.168.178.81 - 192.168.178.254 kannst Du dann statische Adressen auf den Clients einrichten, bzw. die Konfiguration so lassen wie sie ist
Fehler an dieser Stelle sind dann so gut wie ausgeschlossen
| systemctl status network-manager.service
cat /etc/NetworkManager/NetworkManager.conf
|
Den Adresspool für den DHCP-Server hatte ich vor nach dem letzten Reset des Routers zu exakt diesem Intervall (192.168.178.20 - 192.168.178.80) geändert ☺ da hatten wir den selben Gedanken.
Alle statisch vergebenen IP-Adressen sind definitiv außerhalb dieses Intervals. Eigentlich sind es nur jene mit der Endung 101, 102, 103, 240 (und der 241er)
nein der Network-Manager ist mir neu. Weder konfiguriert, entfernt noch gestoppt. Aktuell profitiere ich davon, dass der 102er aus dem Netz gefallen ist, da das ein Ereignis ist, dass nur alle 1-10 Tage auftritt, würde ich zunächst eine exzessive Fehlerdiagnose betreiben. Sobald ich den PC neu starte, würde ich diesen von dir erwähnten Punkt nachholen.
–-
lubux schrieb:
haxxour schrieb:
Problem 2: nach ca. 1-10 Tagen fliegen einige dieser PCs tatsächlich komplett aus dem Netzwerk und das obwohl diese gestartet sind & es das LAN-Kabel unverändert mit der Fritzbox verbindet.
Wie hast Du festgestellt, dass die PCs aus dem Netzwerk geflogen sind?
Poste mal, wenn die PCs aus dem Netzwerk geflogen sind, von einem dieser PCs die Ausgabe von:
sudo arping -c 3 -I <Interface> -s <IP-Adresse-PC> 192.168.178.1
und von einem der PCs der _nicht_ aus dem Netzwerk geflogen ist, die Ausgabe von:
sudo arping -c 3 -I <Interface> -s <IP-Adresse-PC> <IP-Adresse-raus-geflogener-PC>
Mit arping aus dem package iputils-arping:
sudo apt-get install iputils-arping
argpings vom 101er:
$ sudo arping -c 3 -I enp30s0 -s 192.168.178.101 192.168.178.1
ARPING 192.168.178.1 from 192.168.178.101 enp30s0
Unicast reply from 192.168.178.1 [E8:DF:70:8C:E6:D8] 0.873ms
Unicast reply from 192.168.178.1 [E8:DF:70:8C:E6:D8] 0.798ms
Unicast reply from 192.168.178.1 [E8:DF:70:8C:E6:D8] 0.784ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
und
$ sudo arping -c 3 -I enp30s0 -s 192.168.178.101 192.168.178.102
ARPING 192.168.178.102 from 192.168.178.101 enp30s0
Unicast reply from 192.168.178.102 [30:9C:23:61:83:EC] 0.550ms
Unicast reply from 192.168.178.102 [30:9C:23:61:83:EC] 0.556ms
Unicast reply from 192.168.178.102 [30:9C:23:61:83:EC] 0.554ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
–-
Ich starte den 102er am vorerst nicht neu, da ich nicht weiss wann wieder ein PC aus dem Netzwerk fallen könnte.
Wichtige Hinweise: Das Problem betrifft nur Rechner, die über das LAN-Kabel verbunden sind. Unglückerweise haben alle (vier) per LAN verbundenen PCs Ubuntu-Server 16.04 als Betriebssystem, sodass ich nicht sagen kann ob es etwas Ubuntu-Sprezifisches ist. Auf den via WLAN verbundenen Endgeräten (Windows, MAC OS, Android) treten diese Probleme nicht auf.
VG