les requêtes arp ne peuvent pas être vues par des nœuds spécifiques

12

Je crée un WLAN ouvert ad-hoc en utilisant iwconfig(j'ai le même problème avec wpa_supplicant). il y a 4 nœuds sur le réseau comme le montre la figure ci-dessous. Les nœuds exécutent Ubuntu 12.04 et Debian Squeeze, et ont des noyaux 3.7.1, 3.5 et 3.2. J'utilise deux marques de clés USB différentes (TP link et ZCN) qui ont toutes un chipset et un ath9k_htcpilote AR9271 (voici la sortie lsusb et la sortie ethtool ).

Le problème que je rencontre est que deux nœuds ( 10.0.0.2et 10.0.0.5) qui ont des dongles wifi USB TP link peuvent envoyer un ping à n'importe quel nœud du réseau, et vice-versa. Cependant, les autres nœuds ( 10.0.0.6et 10.0.0.7) qui ont un dongle wifi ZCN ne peuvent pas se cingler, mais ils n'ont aucun problème pour communiquer avec les modules wifi TP-link. tcpdumpmontre que 10.0.0.6et 10.0.0.7ne peut pas voir leur requête arp, par exemple

20:37:52.470305 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:53.463713 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:54.463622 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:55.472868 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:56.463439 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:57.463469 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28

mais ils peuvent voir et obtenir des réponses des modules de TP-link.

20:39:23.634459 ARP, Request who-has 10.0.0.2 tell 10.0.0.6, length 28
20:39:23.634551 ARP, Reply 10.0.0.2 is-at 64:70:02:18:d4:6a (oui Unknown), length 28
20:39:23.636687 IP 10.0.0.6 > 10.0.0.2: ICMP echo request, id 572, seq 1, length 64
20:39:23.636809 IP 10.0.0.2 > 10.0.0.6: ICMP echo reply, id 572, seq 1, length 64
20:39:24.635497 IP 10.0.0.6 > 10.0.0.2: ICMP echo request, id 572, seq 2, length 64
20:39:24.635558 IP 10.0.0.2 > 10.0.0.6: ICMP echo reply, id 572, seq 2, length 64
20:39:28.651946 ARP, Request who-has 10.0.0.6 tell 10.0.0.2, length 28
20:39:28.654021 ARP, Reply 10.0.0.6 is-at 00:19:70:94:7c:8b (oui Unknown), length 28

Ma question est que quelle pourrait être la raison pour laquelle 10.0.0.6et 10.0.0.7ne peuvent pas voir arp-requestqu'ils s'envoient mutuellement? Comment puis-je trouver le problème?

Si j'ajoute quelques nœuds supplémentaires avec un dongle wifi ZCN sur le réseau, ces nœuds ne sont pas non plus en mesure de communiquer entre eux, mais ils vont bien avec TP-link. Ou si j'échange les modules wifi, les nœuds avec ZCN ont toujours un problème mais les modules TP-link vont bien. entrez la description de l'image ici

ici est le /etc/network/interfaces, ifconfig, iwconfig, ip a, ip r, routesorties

EDIT: Je soupçonnais si le problème est arp_filterlié mais /proc/sys/net/ipv4/conf/*/arp_filterconcerne 0tous les sous-domaines (*). Si j'ajoute des informations d'arp 10.0.0.6et 10.0.0.7manuellement sur ces nœuds, tcpdumpet wiresharkne montre pas qu'ils s'envoient pingles uns aux autres. Si je pingl'adresse de diffusion (10.0.0.255 dans mon cas), 10.0.0.6et que je peux l' 10.0.0.7entendre.

EDIT2: Voici les fichiers pcap http://filebin.net/6cle9a5iae de 10.0.0.6(module ZCN), 10.0.0.7(module ZCN) et 10.0.0.5(module TP-link qui n'a pas de problème). voici les sorties ping de 10.0.0.6 http://pastebin.com/swFP2CJ9 J'ai capturé les packages simultanément. Le lien comprend également ifconfig; iwconfig; et uname- asorties pour chaque nœud.

linux networking wifi linux-networking arp johan
la source
Pouvez-vous effectuer une capture réseau du trafic ARP sur les machines 10.0.0.6 et 10.0.0.7 en même temps? Utilisez tcp dump et partagez-le en tant que fichier pcap.
Mircea Vutcovici
Merci Mircea Vutcovici, veuillez consulter l'EDIT2 pour les fichiers pcap. Veuillez me faire savoir si vous souhaitez avoir plus d'informations.
johan
Eh bien, vous pouvez essayer d'utiliser l'ARP statique et voir comment / si cela change le problème de connectivité.
poige
Pourriez-vous publier un vidage du trafic à partir d'un outil de renifleur sans fil comme kismet? Cela inclura les en-têtes 802.11 au cas où ils auraient quelque chose d'étrange.
Flup
2
étant donné les problèmes que vous rencontrez avec les dongles ZCN et votre exigence pour que les clients se parlent tous directement sur le réseau, je les jetterais simplement et les remplacerais par les dongles TPLink qui fonctionnent réellement sur votre réseau. Ou cela pourrait être un problème de pilote avec les adaptateurs ZCN - essayez un autre.
août

Réponses:

1

J'ai eu le même problème récemment. J'ai compris que le chipset AR9271 avait un problème sur l'antenne de l'émetteur embarqué. Si vous utilisez une antenne externe, vous n'aurez aucun problème. Et ce problème se produit uniquement en mode ad-hoc.

La raison pour laquelle vous ne rencontrez pas de problème avec la liaison TP devrait être que ces modules utilisent une antenne externe qui surmonte le problème du chipset, et les modules ZCN ne devraient pas avoir d'antenne externe.

Angs
la source
1

Cela pourrait être lié au « problème de nœud caché » si .6 et .7 ne sont pas en contact radio direct, mais sans connaître les distances impliquées, il est impossible de le dire.

De plus, l'un des chipsets ou les deux pourraient avoir un mode ad hoc buggy, il n'est pas beaucoup utilisé de nos jours et ne serait pas surprenant.

LapTop006
la source