ARP-Antworten enthalten eine falsche MAC-Adresse

Ich habe einen Linux-Roboter mit kabelgebundenen und kabellosen Adaptern. Wenn ich hochfahre, stellt es eine Verbindung zur drahtlosen Geldstrafe her. Wenn ich dem Kabel eine IP zugebe (entweder statisch oder mit DHCP), sieht es so aus, als würde es funktionieren. Wie in, ifconfigzeigt eine richtige IP und routezeigt die richtigen Routen. Wenn ich jedoch eine ARP-Anforderung der verdrahteten IP-Adresse durchführe, enthält die ARP-Antwort den drahtlosen MAC.

??? Auf dem Roboter läuft keine Brücke. Warum bekomme ich nicht den verdrahteten MAC ???

Wenn die Verbindung getrennt wird, antwortet die verkabelte IP auf Ping ...

Warum antwortet der Roboter über die drahtlose Schnittstelle auf IP-Anfragen auf dem Kabel?

BEARBEITEN: Sowohl die kabelgebundenen als auch die kabellosen Adapter im selben IP-Subnetz. Ich führe eine ARP-Anfrage von einem Computer aus (mit verschiedenen Computern ausprobiert), der sich im selben IP-Subnetz befindet.

relevante ifconfig Ausgabe:

eth0      Link encap:Ethernet  HWaddr 00:01:C0:04:BD:F7  
          inet addr:192.168.0.110  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST 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)
ra0       Link encap:Ethernet  HWaddr 24:3C:20:06:3E:6D  
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:59 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:31023598 (29.5 MiB)  TX bytes:85640627 (81.6 MiB)

relevante Routenausgabe:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ra0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Es ist ein sehr reduziertes Linux, daher habe ich keine Tools wie artptables, iptables, sysctl, brctl usw.

EDIT: Diagramm wie gewünscht

EDIT: Ich lade den Verkehr und schaue auf den ARP-Tisch. Eine ARP-Anforderung von 192.168.0.110 gibt eine ARP-Antwort mit 24: 3C: 20: 06: 3E: 6D zurück. Der Quell-MAC des ARP-Antwortpakets ist ebenfalls 24: 3C: 20: 06: 3E: 6D. Ich habe versucht, mit _filter, _ignore und _announce zu fummeln, wie hier erwähnt , aber ohne Erfolg.

BEARBEITEN: Das Einstellen eines Gateways (auf beiden Schnittstellen) macht keinen Unterschied (wie es nicht sein sollte).

BEARBEITEN: Dies funktionierte gut auf einer früheren Version des Betriebssystems (basierend auf openembedded). ist es möglich, dass sie etwas geändert haben?

Was Sie sehen, ist normales Verhalten, wenn Sie zwei Schnittstellen in demselben Netzwerk haben. Es wird in diesem LWN-Artikel beschrieben .

Wenn Sie sagen, dass Sie eine ARP-Antwort für die falsche Schnittstelle erhalten, führen Sie dann tatsächlich ein Dumping des Datenverkehrs durch oder sehen Sie sich nur die resultierende ARP-Tabelle an? Möglicherweise erhalten Sie ARP-Antworten für beide Schnittstellen ...

Wie auch immer, ich glaube, die Antwort auf Ihr Problem liegt in der richtigen Manipulation rp_filterund arp_filter. Die Dokumentation für jeden von ihnen ist unten enthalten.

Ich schlage vor, zuerst Folgendes zu versuchen:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Möglicherweise müssen Sie diese Änderung auch vornehmen:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

rp_filter - BOOLEAN
    1 - Überprüfen Sie die Quelle anhand des umgekehrten Pfads, wie in RFC1812 angegeben
        Empfohlene Option für einzelne Hosts und Stub-Netzwerke
        Router. Könnte Probleme verursachen für komplizierte (nicht schleifenfrei)
        Netzwerke, die ein langsames, unzuverlässiges Protokoll ausführen (Art von RIP),
        oder mit statischen Routen.

    0 - Keine Quellenüberprüfung.

    conf / all / rp_filter muss ebenfalls auf TRUE gesetzt sein, um die Quellvalidierung durchzuführen
    auf der Schnittstelle

    Der Standardwert ist 0. Beachten Sie, dass einige Distributionen dies ermöglichen
    in Startskripten.

arp_filter - BOOLEAN
    1 - Ermöglicht es Ihnen, mehrere Netzwerkschnittstellen auf derselben zu haben
    Subnetz und lassen die ARPs für jede Schnittstelle beantworten
    basierend darauf, ob der Kernel ein Paket von weiterleiten würde oder nicht
    das ARP'd IP aus dieser Schnittstelle (daher müssen Sie Quelle verwenden
    basiertes Routing, damit dies funktioniert). Mit anderen Worten, es ermöglicht die Kontrolle
    von denen Karten (normalerweise 1) auf eine Arp-Anfrage antworten.

    0 - (Standard) Der Kernel kann auf Arp-Anfragen mit Adressen antworten
    von anderen Schnittstellen. Das mag falsch erscheinen, macht es aber normalerweise
    Sinn, weil es die Chance auf erfolgreiche Kommunikation erhöht.
    IP-Adressen gehören dem vollständigen Host unter Linux, nicht
    bestimmte Schnittstellen. Nur für komplexere Setups wie Load-
    Ausbalancieren, verursacht dieses Verhalten Probleme.

    arp_filter für die Schnittstelle wird aktiviert, wenn mindestens einer von
    conf / {all, interface} / arp_filter ist auf TRUE gesetzt,
    es wird sonst deaktiviert

Weitere Informationen finden Sie in diesem Artikel:

http://www.embedded-bits.co.uk/tag/rp_filter/

Ich weiß, dass dies ein altes Problem ist, aber ich bin kürzlich auf genau dieselbe Situation mit einem eingebetteten Gerät gestoßen. Das Gerät verfügt sowohl über eine Ethernet- als auch eine WLAN-Schnittstelle. Die Anforderungen bestehen darin, dass beide Schnittstellen jederzeit aktiv und im selben Netzwerk sein können, der Netzwerkverkehr jedoch über die "bevorzugte" Schnittstelle geleitet werden muss.

Die meisten Benutzer würden ihre Geräte nicht so konfigurieren, aber theoretisch sollte dies möglich sein.

Wir haben zuerst die Probleme mit Netgear-Routern aufgegriffen, weil sie einen IP-Adressenkonflikt melden würden - 2 MAC-Adressen teilten sich eine einzelne IP. Anscheinend würde sich der Router in diesem Szenario schlecht verhalten und das Netzwerk des Benutzers durcheinander bringen.

Ich habe ein privates Netzwerk erstellt, das nur den Router (Ethernet + WLAN), Windows Laptop (nur Ethernet) und das eingebettete Gerät (Ethernet + WLAN) enthielt. Unter Verwendung von wireshark, tcpdump auf dem Gerät und arp unter Windows kann ich folgendes Verhalten feststellen:

1. Ifconfig auf dem Gerät zeigt unterschiedliche WLAN- und Ethernet-IPs sowie unterschiedliche MAC-Adressen an
2. Manchmal (sehr selten) und arp –a von Windows zeigt die richtige IP-MAC-Kombination.
3. Die meiste Zeit zeigt arp –a in Windows, dass sowohl wln als auch eth0 dieselbe MAC-Adresse haben
4. Wenn Sie unter Windows entweder wln oder eth0 anpingen, kommt die Ping-Antwort von wln und sehr selten von eth0. tcpdump zeigt, dass wln nur auf 1 der 4 Pings geantwortet hat (zum Beispiel)
5. Wenn Windows eine arp-Nachricht "who has" für die eth0-IP sendet, antworten sowohl die eth0- als auch die wln-Schnittstelle mit der Meldung, dass sie diese IP haben

Ich glaube, dass Punkt 3 von Punkt 5 verursacht wird. Die Arp-Tabellen sind durcheinander, weil der Wln auf Arp-Nachrichten antwortet, auf die nur eth0 antworten sollte. Ich glaube, Punkt 4 wird auch von Punkt 5 verursacht. Ping wird basierend auf der MAC-Adresse gesendet, und da die letzte empfangene Arp-Nachricht von wln lautete, dass sie die eth0-IP hat, werden die Pings falsch an die wln-Schnittstelle weitergeleitet.

Nach langem Graben und Testen war die Lösung eigentlich ganz einfach. Siehe diesen Artikel - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Die Linux-Kernel-Netzwerktreiber sind so konfiguriert, dass beim Empfang einer Arp-Anforderung für eine bekannte Schnittstelle (auch wenn sie auf einer anderen Schnittstelle empfangen wird) diese auf die Arp-Anforderung reagiert.

Diese Einstellung behebt das Problem:

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

Erläuterung:

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied

Da dies in einer früheren Version des Betriebssystems (basierend auf openembedded) problemlos funktionierte, bestand meine Lösung darin, auf die nächste Version des Betriebssystems zu warten. Mein bester Tipp war, dass das drahtlose Kernelmodul fehlerhaft war.

Insytes Kommentar weiterverfolgen.

Lasst uns etwas benennen:

• PC1 - Oben rechts
• PC2 - Oben links
• PC3 - Unten links

Denn Sie haben Ihren Roboter von den 3 PCs aus sowohl über kabelgebundene als auch über kabellose Medien erreichbar. Und da sie sich im selben Subnetz befinden, können Sie nicht sicher sagen, auf welche Weise die Arp-Anforderung für Ihre kabelgebundenen Medien erfolgt ist. Damit meine ich , was ist , wenn die Schalter Sendungen für einen ARP - Request, den Roboter es auf beiden Schnittstellen empfängt [Bezugnahme auf das Diagramm] so für die arp Anforderung für die IP auf den verkabelte Medien auf den empfängt drahtlose Medien zu stehen die Chancen, Es antwortete mit der physischen Adresse des drahtlosen Mediums für die Box, in der diese IP konfiguriert ist

Ich hatte dieses Problem in der Vergangenheit, es war nicht genau für Sie, aber es war ähnlich. Standardmäßig antwortet Linux mit der physischen Adresse der Schnittstelle, auf der es die Arp-Anforderung empfängt, unabhängig davon, auf welcher Schnittstelle die IP konfiguriert ist. Schließen Sie also in Ihrem Fall PC3 direkt an die eth0-Schnittstelle des Roboters an und führen Sie eine ARP-Anfrage für 192.168.0.101 durch. Sie erhalten dann die physikalische Adresse der eth0-Schnittstelle anstelle von ra0.

Mein Einsatzszenario war:

[RTR] | ------------ eth0 --- [Server]
| -------- | switch1 | ----- eth1 ----- [server]

Es ist derselbe Switch, mit dem beide Schnittstellen verbunden sind. Hoffentlich würde es dir helfen.

Der Router hat auf seiner Schnittstelle eine primäre und eine sekundäre IP-Adresse für zwei verschiedene Netzwerke auf den zwei verschiedenen Schnittstellen des Servers konfiguriert. Als er jedoch eine arp-Anfrage auf eth1 für die IP-Adresse von eth0 erhielt, antwortete er mit der physischen Adresse von eth1

Um dies zu verhindern, hat folgendes bisher bei mir funktioniert

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

Legen Sie es irgendwo auf Ihren Roboter, damit Sie es beim Booten anwenden können.

Empfehlungen: Ich würde empfehlen, dass Sie zwei verschiedene Subnetze konfiguriert haben (z. B. 192.168.1.x / 24 auf ra0 und 192.168.2.x / 24 auf eth0). Sie können IP-Aliase auf Ihren PCs verwenden, und Ihr Roboter ist über jeden erreichbar der beiden IPs. Sie können nicht zwei ausgehende Pfade für dasselbe Subnetz auf demselben Host haben. Es sei denn, es gibt etwas, das Ihren Roboter einander vorziehen lässt. Ihr Roboter kann nur einen Weg nehmen, um Pakete aus ihm heraus zu senden.

Einige Lesungen: arp_announce , arp_ignore

Ich denke, es gibt eine Fehlkonfiguration zwischen Ihrem WLAN-Zugangspunkt und Ihrem Switch. Switch und AP werden verwirrt, wohin Pakete gesendet werden sollen. Ich bin mir jedoch nicht sicher. Ich denke auch, Sie sollten versuchen, ein Gateway zu definieren, in dem Programme wissen, wohin Pakete gesendet werden sollen. etwas wie

route add default gw 192.168.0.1