Ping nicht möglich, aber Wireshark zeigt Pakete an

Ping nicht möglich, aber Wireshark zeigt Pakete an

Ich versuche zu überprüfen, ob meine Ethernet-Netzwerkschnittstelle richtig funktioniert oder nicht. Ich habe zwei PCs und sie sind direkt verbunden (ohne Switch). Auf einem PC habe ich versucht, den anderen mit zugewiesener IP anzupingen, aber ich erhalte die Meldung „Zielhost nicht erreichbar“. Ich habe Wireshark überprüft und dort erhalte ich sowohl eine ARP-Anfrage als auch eine Antwort vom zweiten PC (ich überprüfe den zweiten PC). Dann habe ich es umgekehrt überprüft und festgestellt, dass mein erster PC auf keine ARP-Anfragen antwortet. Irgendeine Idee, was diesen Fehler verursacht?

My settings: PC 1

ink encap:Ethernet  HWaddr 6c:b3:11:52:12:a5  
          inet addr:10.0.0.2  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::66b3:11ff:fe52:2a9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
PC 2
ink encap:Ethernet  HWaddr 6c:b3:11:52:72:a0  
          inet addr:10.0.0.3  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::66b3:12ff:fe52:2a9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:284 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (480.0 B)  TX bytes:0 (34.4 KB)

Von PC 1 aus habe ich ip route ls ausprobiert und bekam

10.0.0.0/24 dev enp1s0  proto kernel  scope link  src 10.0.0.2

Habe einige Kommentare zur Firewall gesehen, aber hier ist, was ich bekomme, wenn ich nachschaue

home# cat /etc/sysconfig/iptables                                                              
cat: /etc/sysconfig/iptables: No such file or directory

EDIT 1: Ergebnis der IP-Route auf PC2

home$ip route ls
default via 172.16.0.1 dev eth0 proto static
10.0.0.0/24 dev eth1 proto kernel scoope link src 10.0.0.3 metric 1
172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.2.3 metric 1

Versuchte ping6 fe80::66b3:11ff:fe52:2a9 -I eth1 bekam Destination unreachable, address unreachableFehler Gleiches Ergebnis für andersherum

Notiz: (Falls es relevant ist) In PC2 habe ich zwei Netzwerkkarten und versuche über eth1 zu kommunizieren

Antwort1

Unter der Annahme, dass Sie die beiden PCs mit einemordnungsgemäß konstruiertes Crossover-Kabeloder mindestens eines der Geräte unterstütztAuto-MDIX, mir fallen nur zwei Gründe ein, warum dies passieren könnte.

A) Blockierte ICMP-Echoanforderungen auf Port 7 durch Firewall

B) Die Netzwerkkarte von PC1 ist defekt (sowohl Sender als auch Empfänger sind ausgefallen) und sollte ersetzt werden.

Notiz:

Auto-MDI-X ist Teil des 1000BASE-T-Standards und hat patentierte Algorithmen für „Forced Mode Auto-MDI-X“ entwickelt, die eine automatische Verbindungsherstellung ermöglichen, auch wenn der Port nicht automatisch verhandelt. Dies kann auf einem bestimmten Gerät implementiert sein oder nicht, daher kann es gelegentlich vorkommen, dassein Crossover-Kabel kann dennoch erforderlich seinbeim Anschluss von Auto-MDI-X an MDI-X (Hub oder Switch),insbesondere wenn Auto-Negotiation deaktiviert ist.

Neuere Router, Hubs und Switches (darunter in der Praxis auch einige 10/100- und alle 1-Gigabit- oder 10-Gigabit-Geräte) verwenden Auto-MDI-X für 10/100-Mbit-Verbindungen, um nach dem Anschließen eines Kabels automatisch zur richtigen Konfiguration zu wechseln.

Gigabit- und schnellere Ethernet-Verbindungenüber Twisted Pair KabelNutzung aller vier Kabelpaare zur gleichzeitigen Übertragung in beide Richtungen. Aus diesem Grund gibt es keine dedizierten Sende- und Empfangspaare, und folglichFür die 1000BASE-T-Kommunikation sind keine Crossover-Kabel erforderlich.Die Unterschicht für die physische Medienanbindung (PMA) dient zur Identifizierung jedes Paares und funktioniert normalerweise auch über Kabel, bei denen die Paare ungewöhnlich vertauscht oder gekreuzt sind.

Unter der Annahme, dass Sie mit Wireshark Pakete in beide Richtungen auf PC2 und NICHT auf PC1 sehen, und ohne weitere Details zur verwendeten Hardware, ist meine beste Vermutung B). Ich hoffe, das hilft.

verwandte Informationen