☰

Linux-Gerät während Netzwerkbetrieb (Ping) nicht erreichbar

tag-icon • tag-icon networking ethernet
Linux-Gerät während Netzwerkbetrieb (Ping) nicht erreichbar

Ich habe ein Setup mit meinem Windows-PC, einem Switch und einem Linux-SBC (nicht Raspberry) und versuche, den SBC über den Switch mit meinem Computer zu verbinden, um dem SBC Internet und SSH bereitzustellen.

Der SBC gibt folgende IP-Adressen aus

root@imx6qpdlsolox:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.234.40  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::204:9fff:fe06:3984  prefixlen 64  scopeid 0x20<link>
        ether 00:04:9f:06:39:84  txqueuelen 1000  (Ethernet)
        RX packets 364  bytes 45484 (44.4 KiB)
        RX errors 0  dropped 166  overruns 0  frame 0
        TX packets 140  bytes 35993 (35.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 446  bytes 29426 (28.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 446  bytes 29426 (28.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Mein Computer gibt folgendes aus

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::4ece:1a02:7677:2d01%22
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.200
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   IPv4-Adresse  . . . . . . . . . . : 192.254.79.200
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   IPv4-Adresse  . . . . . . . . . . : 169.254.234.200
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway .

Ich kann den SBC von meinem Computer aus anpingen

Ping wird ausgeführt für 169.254.234.40 mit 32 Bytes Daten:
Antwort von 169.254.234.40: Bytes=32 Zeit<1ms TTL=64
Antwort von 169.254.234.40: Bytes=32 Zeit<1ms TTL=64
Antwort von 169.254.234.40: Bytes=32 Zeit<1ms TTL=64
Antwort von 169.254.234.40: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 169.254.234.40:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Aber nicht mein Computer vom SBC

root@imx6qpdlsolox:~# ping 169.254.234.200
PING 169.254.234.200 (169.254.234.200) 56(84) bytes of data.

Beide Geräte sind über den Switch verbunden. Der Switch bestätigt dies und die LEDs blinken. Die grüne LED am SBC blinkt nicht, die orangene jedoch schon. Was bedeutet das? Ich habe gelesen, dass grün eine erfolgreiche Verbindung bedeutet, das Board also keine Verbindung hat. Aber warum zeigt der Switch dann eine erfolgreiche Verbindung an und warum funktioniert ein Ping?

Antwort1

Windows verfügt standardmäßig über eine Firewall, die nahezu alle eingehenden Daten blockiert – sogar Ping-Anfragen.

Führen Sie es wf.mscunter Windows aus, öffnen Sie „Eingehend“ und aktivieren Sie die integrierten Regeln „ICMP Echo“ und „ICMPv6 Echo“. Sie finden sie unter „Core Network Diagnostics“ in Windows 11 oder unter „File Sharing“ in Windows 10 (letzteres beschränkt sie standardmäßig auch nur auf dasselbe Subnetz).

Versuchen Sie außerdem, die Netzmasken für alle Geräte in einem bestimmten Subnetz identisch zu halten. Derzeit verwendet Ihr SBC 255.255.0.0, aber der PC ist so konfiguriert, dass er 255.255.255.0für seine Adresse 169.254.234.200 verwendet. In diesem Fall ist es zwar nichtnochDies verursacht zwar Probleme (da sich sowohl die Adressen des SBC als auch die des PCs noch innerhalb der engeren der beiden Netzmasken befinden), es wird jedoch dennoch als Fehlkonfiguration gewertet.

Daher sollte die Adresse 169.254.234.200 des PCs idealerweise so geändert werden, dass sie die Netzmaske 255.255.0.0 verwendet. (Die anderen IP-Adressen des PCs können weiterhin ihre aktuellen Netzmasken verwenden.)

Ping ist eine bidirektionale Prüfung, die zwei Dinge (Anfrage und Antwort) zu einem einzigen Pass/Fail kombiniert. Wenn es fehlschlägt, besteht der nächste Schritt darin, diese Dinge zu überprüfenseparat,d. h. Sie möchten herausfinden, ob der Computer die Ping-Anforderung des SBC empfängt, ohne sich auf die Antwort zu verlassen.

Dazu werden Tools zur Paketerfassung verwendet (normalerweise Wireshark für die Windows/Linux-GUI oder tcpdump für die CLI). Selbst wenn der Computer nicht antwortet, können Sie durch die Anzeige der beim Computer eingehenden Anfrage erkennen, dass die Netzwerkkonfiguration des SBC korrekt (oder zumindest halbwegs korrekt) ist und dass es daher der Computer ist, der nicht antwortet. (Oder es zeigt Ihnen möglicherweise an, dass der Computer über eine andere Schnittstelle antwortet, weil Sie die falsche Netzmaske angegeben haben...)

Die grüne LED auf dem SBC blinkt nicht, die orange aber schon. Was bedeutet das? Ich habe gelesen, dass grün eine erfolgreiche Verbindung bedeutet, also hat das Board keine Verbindung

Ethernet-LED-Anzeigen verfügen über kein standardmäßiges Farbschema; was Sie über Netzwerk-LEDs auf einem Gerät gelesen haben, gilt nicht unbedingt auch für ein anderes.

Beispielsweise könnte es sein, dass der SBC „Orange = 100 Mbit/s“ und „Grün = 1 Gbit/s“ verwendet, wobei jede der Farben eine erfolgreiche Verbindung, aber unterschiedliche Bitraten anzeigt. (Ich habe auch das Gegenteil gesehen, wobei Orange die höhere Geschwindigkeit anzeigt.)

verwandte Informationen