Les réponses ARP contiennent une mauvaise adresse MAC

J'ai un robot sous Linux avec des adaptateurs filaires et sans fil. Lorsque je démarre, il se connecte à l'amende sans fil. Lorsque j'attribue une adresse IP au filaire (de manière statique ou avec DHCP), il semble que cela fonctionne. Comme dans, ifconfigaffiche une adresse IP appropriée et routeaffiche les itinéraires appropriés. Cependant, lorsque je fais une demande ARP de l'IP filaire, la réponse ARP contient le MAC sans fil.

??? Il n'y a pas de pont en cours d'exécution sur le robot, alors pourquoi ne pas obtenir le MAC câblé ???

Lorsque le fil est déconnecté, l'IP câblée répond au ping ...

Pourquoi le robot répond-il via l'interface sans fil aux requêtes IP sur le câble ???

EDIT: les adaptateurs filaires et sans fil sur le même sous-réseau IP. Je fais une demande ARP à partir d'un ordinateur (essayé avec différents ordinateurs) sur le même sous-réseau IP.

sortie ifconfig pertinente:

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)

sortie d'itinéraire appropriée:

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

C'est un linux très simple, donc je n'ai pas d'outils comme artptables, iptables, sysctl, brctl, etc.

EDIT: diagramme comme demandé

EDIT: Je vide le trafic et regarde la table ARP. Une demande ARP de 192.168.0.110 renvoie une réponse ARP contenant 24: 3C: 20: 06: 3E: 6D. Le MAC source du paquet de réponse ARP est également 24: 3C: 20: 06: 3E: 6D. J'ai essayé de jouer avec _filter, _ignore et _announce, comme mentionné ici , mais en vain.

EDIT: la définition d'une passerelle (sur l'une ou l'autre interface) ne fait aucune différence (comme cela ne devrait pas).

EDIT: cela a bien fonctionné sur une version précédente du système d'exploitation (basé sur openembedded). est-il possible qu'ils aient changé quelque chose?

Ce que vous voyez est un comportement normal lorsque vous avez deux interfaces sur le même réseau. Il est décrit dans cet article LWN .

Lorsque vous dites que vous obtenez une réponse ARP pour la mauvaise interface, êtes-vous en train de vider le trafic ou simplement de regarder la table ARP résultante? Il est possible que vous obteniez des réponses ARP pour les deux interfaces ...

Quoi qu'il en soit, je crois que la réponse à votre problème réside dans la manipulation correcte rp_filteret arp_filter. La documentation pour chacun d'eux est incluse ci-dessous.

Je suggère d'abord d'essayer ceci:

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

Vous devrez peut- être également effectuer cette modification:

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

rp_filter - BOOLEAN
    1 - faire la validation de la source par un chemin inversé, comme spécifié dans RFC1812
        Option recommandée pour les hôtes à hébergement unique et le réseau de stub
        routeurs. Pourrait causer des problèmes pour compliqué (pas sans boucle)
        les réseaux exécutant un protocole lent et peu fiable (sorte de RIP),
        ou en utilisant des routes statiques.

    0 - Aucune validation de source.

    conf / all / rp_filter doit également être défini sur TRUE pour effectuer la validation de la source
    sur l'interface

    La valeur par défaut est 0. Notez que certaines distributions le permettent
    dans les scripts de démarrage.

arp_filter - BOOLEAN
    1 - Vous permet d'avoir plusieurs interfaces réseau sur le même
    sous-réseau, et avoir les ARP pour chaque interface être répondu
    selon que le noyau acheminerait ou non un paquet
    l'IP ARP sur cette interface (vous devez donc utiliser la source
    routage basé pour que cela fonctionne). En d'autres termes, il permet un contrôle
    dont les cartes (généralement 1) répondront à une demande d'arp.

    0 - (par défaut) Le noyau peut répondre aux requêtes arp avec des adresses
    à partir d'autres interfaces. Cela peut sembler faux, mais cela fait généralement
    sens, car il augmente les chances de réussite de la communication.
    Les adresses IP appartiennent à l'hôte complet sous Linux, pas à
    interfaces particulières. Uniquement pour les configurations plus complexes comme le chargement
    l'équilibrage, ce comportement pose-t-il des problèmes.

    arp_filter pour l'interface sera activé si au moins l'un des
    conf / {all, interface} / arp_filter est défini sur TRUE,
    il sera désactivé sinon

Pour un traitement plus approfondi, consultez cet article:

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

Je sais que c'est un ancien problème, mais j'ai récemment rencontré exactement la même situation avec un appareil intégré. L'appareil possède à la fois une interface ethernet et wifi et les exigences sont que les deux interfaces peuvent être actives et sur le même réseau à tout moment, mais le trafic réseau doit être acheminé via l'interface "préférée".

La plupart des utilisateurs ne configureraient pas leurs appareils de cette façon, mais en théorie, cela devrait être possible.

Nous avons d'abord identifié les problèmes avec les routeurs Netgear car ils signalaient un conflit d'adresse IP - 2 adresses MAC partageaient une seule IP. Apparemment, le routeur commencerait à mal se comporter dans ce scénario et gâcherait le réseau des utilisateurs.

J'ai créé un réseau privé qui ne contenait que le routeur (Ethernet + wifi), un ordinateur portable Windows (Ethernet uniquement) et le périphérique intégré (Ethernet + wifi). En utilisant Wireshark, tcpdump sur l'appareil et arp sur Windows, je peux voir le comportement suivant:

1. Ifconfig sur le périphérique affiche des adresses IP wln et Ethernet distinctes et des adresses MAC distinctes
2. Parfois (très rarement) et arp –a de Windows affiche la bonne combinaison IP-MAC.
3. La plupart du temps, l'arp –a de Windows montre que wln et eth0 ont la même adresse MAC
4. Lorsque vous envoyez une requête ping à wln ou eth0 à partir de Windows, la réponse ping provient de wln et très rarement de eth0. tcpdump montre que le wln n'a répondu qu'à 1 des 4 pings (par exemple)
5. Lorsque Windows envoie un message arp "who has" pour l'eth0 IP - les interfaces eth0 et wln répondent en disant qu'elles ont cette IP

Je crois que l'élément 3 est causé par l'élément 5. Les tables d'arp sont gâchées parce que le wln répond aux messages d'arp auxquels seul eth0 devrait répondre. Je crois que le point 4 est également causé par le point 5. Le ping est envoyé en fonction de l'adresse MAC et puisque le dernier message arp reçu était de wln disant qu'il a l'IP eth0, les pings sont acheminés de manière incorrecte vers l'interface wln.

Après beaucoup de fouilles et de tests, la solution était vraiment très simple. Voir cet article - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Les pilotes réseau du noyau Linux sont configurés de telle manière que lorsqu'une demande d'arp est reçue pour une interface connue (même si elle est reçue sur une autre interface), elle répondra à l'arp.

Ce paramètre résout le problème:

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

Explication:

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

Comme cela fonctionnait bien sur une version précédente du système d'exploitation (basé sur openembedded), ma solution était d'attendre la prochaine version du système d'exploitation. Ma meilleure supposition était que le module du noyau sans fil était bogué.

Suivi du commentaire d'Insyte.

Permet de nommer:

• PC1 - En haut à droite
• PC2 - En haut à gauche
• PC3 - En bas à gauche

Car vous avez votre robot accessible depuis les 3 PC via des supports filaires et sans fil. Et comme ils se trouvent sur le même sous-réseau, vous ne pouvez pas savoir avec certitude de quelle manière la demande d'arp pour votre support filaire est passée. Par cela, ce que je veux dire, c'est lorsque le commutateur diffuse une demande d'arp, votre robot la reçoit sur les deux interfaces [en vous référant à votre diagramme], donc pour lui, il reçoit la demande d'arp pour l'IP sur le support filaire sur le support sans fil trop de chances sont il a répondu avec l'adresse physique du support sans fil pour que la boîte ait cette IP configurée

J'ai eu ce problème dans le passé, il n'était pas exact pour le vôtre mais était similaire. Par défaut, Linux répond avec l'adresse physique de l'interface sur laquelle il reçoit la requête arp, quelle que soit l'interface sur laquelle l'IP est configuré. Donc, dans votre cas, connectez directement PC3 à l'interface eth0 du robot et faites une demande d'arp pour 192.168.0.101, il vous répondra avec l'adresse physique de l'interface eth0 au lieu de ra0.

Mon scénario de déploiement était:

[RTR] | ------------ eth0 --- [serveur]
| -------- | switch1 | ----- eth1 ----- [serveur]

C'est le même commutateur auquel les deux interfaces se connectent. Espérant que cela vous aiderait.

Le routeur avait une adresse IP principale et secondaire configurée sur son interface pour deux réseaux différents sur les deux interfaces différentes sur le serveur. Mais en recevant une requête arp sur eth1 pour l'adresse IP de eth0, il a répondu avec l'adresse physique de eth1

Pour l'empêcher, ce qui suit a jusqu'à présent fonctionné pour moi

# 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

placez-le quelque part sur votre robot afin que vous puissiez l'appliquer au démarrage.

Recommandations: je recommanderais que deux sous-réseaux différents soient configurés (disons 192.168.1.x / 24 sur ra0 et 192.168.2.x / 24 sur eth0), vous pouvez utiliser des alias IP sur vos PC et votre robot serait accessible sur n'importe quel des deux adresses IP. Vous ne pouvez pas avoir deux chemins sortants pour le même sous-réseau sur un même hôte. Sauf s'il y a quelque chose qui fait que votre robot préfère l'un à l'autre. Votre robot ne peut emprunter qu'un seul chemin pour en envoyer des paquets.

Quelques lectures: arp_announce , arp_ignore

je pense qu'il y a une mauvaise configuration entre votre point d'accès sans fil et votre commutateur. le commutateur et AP deviennent confus où envoyer des paquets. pas sûr cependant. aussi, je pense que vous devriez essayer de définir une passerelle où les programmes peuvent savoir où envoyer des paquets. quelque chose comme

route add default gw 192.168.0.1