Les réponses ARP contiennent une mauvaise adresse MAC


14

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é

diagramme de réseau

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?


5
peut-être qu'un diagramme serait cool, et que vous pourriez y mettre un robot ... des points super sympas
The Unix Janitor

Les adaptateurs câblés et sans fil se trouvent-ils sur le même sous-réseau IP? D'où "faites-vous une demande ARP"? Il pourrait être utile d'inclure les résultats de «ifconfig» et d'afficher votre table de routage.
Dave

Est-ce que cela a jamais été résolu? Je vois un problème similaire et je n'ai pas réussi à trouver la résolution.
Kirk

1
je crois que le module de noyau pour la carte sans fil a été cassé.
Jayen

1
La question est POURQUOI faites-vous cela ... Je suppose que vous le voulez pour que lorsque le robot est mobile, il puisse parler, mais lorsque vous branchez un câble Ethernet, vous pouvez obtenir des vitesses de transfert élevées? Si oui, avez-vous envisagé de lier les interfaces filaires et sans fil, en les mettant toutes les deux sur la même IP, puis en les configurant de sorte que si le câble est en place, il devienne prioritaire, mais sinon, le trafic passe par le sans fil? J'avais l'habitude de configurer mon ordinateur portable de cette façon et cela fonctionnait très bien, mais maintenant j'ai 300Mbps sans fil plutôt que 2Mbps, donc je ne fais plus ça.
Sean Reifschneider

Réponses:


12

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 .


définir arp_filter n'a aucun effet. pourquoi pas?
Jayen

1
Puisque vos deux interfaces ont des routes vers le réseau local, linux enverra des paquets depuis l'une de vos adresses IP vers l'une de vos interfaces. Ainsi, il répondra aux demandes ARP pour l'une de vos adresses IP à partir des deux interfaces. Pour changer cela, vous devez non seulement définir arp_filter sur 1, vous devez également activer le routage basé sur la source et configurer des tables de routage qui garantissent que le trafic pour chaque IP sort de l'interface souhaitée. C'est un scénario légèrement différent de ce que vous avez, mais wlug.org.nz/SourceBasedRouting pourrait vous aider.
sciurus

4

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/


1
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 est également 24: 3C: 20: 06: 3E: 6D. J'ai essayé les deux paramètres de filtre suggérés, mais en vain. J'ai également essayé de jouer avec _ignore et _announce, comme mentionné ici .
Jayen

4

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

Réponse très informative, mais comme l'OP l'a dit, il a essayé cela et lié à la réponse similaire serverfault.com/a/30648/57200
Jayen

1

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é.


Peu probable, car le comportement que vous rencontrez est attendu comme mentionné par @sciurus. Il se peut que la version précédente où cela fonctionnait bien était la version buggy et ils l'ont corrigée :-). En fait, c'est juste celui qui répond en dernier est celui qui reste dans la table ARP à l'extrémité distante. Étant donné que le sans fil est probablement plus lent que le filaire, vous allez obtenir le sans fil.
Sean Reifschneider

0

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


arp_announce & arp_ignore ne fonctionnaient pas pour moi. voir mon commentaire sur la solution d'insyte. Deux sous-réseaux différents ne sont malheureusement pas une option. En outre, comme lors de la dernière modification de ma question, cela a bien fonctionné sur une version précédente du système d'exploitation, donc je peux avoir deux chemins sortants pour le même sous-réseau sur un même hôte.
Jayen

-2

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


les ordinateurs portables sur le filaire et le sans fil fonctionnent bien, donc ce n'est pas l'AP ou le commutateur. aussi, une passerelle n'est nécessaire que lorsque j'essaie de sortir du sous-réseau. (Je l'ai quand même essayé, et cela ne change rien. Peu importe si j'ajoute la passerelle à eth0 ou ra0.)
Jayen

il n'y a pas de RX / TX sur votre eth0, indique une config. Erreur?
fmysky

hrm, je suppose que c'est vrai. eth0 devrait au moins recevoir la requête ARP, car il s'agit d'une diffusion, non?
Jayen

oui, c'est ce que je pensais
fmysky

problème d'arp dans cet article lwn ne semble affecter que les noyaux
2.4.x
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.