As solicitações arp não podem ser vistas por nós específicos

Eu crio uma WLAN ad-hoc aberta usando iwconfig(eu também tenho o mesmo problema wpa_supplicant). existem 4 nós na rede, como mostra a figura abaixo. Os nós executam o ubuntu 12.04 e o debian squeeze, e possuem os núcleos 3.7.1, 3.5 e 3.2. Eu uso duas marcas diferentes de dongle usb (link TP e ZCN) que possuem chipset e ath9k_htcdriver AR9271 (aqui estão as saídas lsusb e ethtool ).

O problema que estou enfrentando é que dois nós ( 10.0.0.2e 10.0.0.5) que possuem dongles wi-fi USB com link TP podem executar ping em qualquer nó da rede e vice-versa. No entanto, os outros nós ( 10.0.0.6e 10.0.0.7) que possuem o dongle wifi ZCN não podem efetuar ping um ao outro, mas não têm problemas para se comunicar com os módulos wifi do link TP. tcpdumpmostra isso 10.0.0.6e 10.0.0.7não pode ver sua solicitação arp, por exemplo

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

mas eles podem ver e obter respostas dos módulos da 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

Minha pergunta é: qual poderia ser a razão disso 10.0.0.6e 10.0.0.7não pode ver o arp-requestque eles enviam um ao outro? Como posso descobrir o problema?

Se eu adicionar mais alguns nós com o dongle wifi ZCN na rede, esses nós também não poderão se comunicar, mas estão bem com o TP-link. Ou, se eu trocar os módulos wifi, os nós com ZCN sempre têm problemas, mas os módulos de link TP estão bem.

aqui é a /etc/network/interfaces, ifconfig, iwconfig, ip a, ip r, routesaídas

Edição: Eu suspeitava se o problema está arp_filterrelacionado, mas /proc/sys/net/ipv4/conf/*/arp_filterestá 0em todos os subdomínios (*). Se eu adicionar informações de ARP 10.0.0.6e 10.0.0.7manualmente nesses nós, tcpdumpe wiresharknão mostrar que eles são enviados pingum para o outro. Se eu pingo endereço de transmissão (10.0.0.255 no meu caso), 10.0.0.6e 10.0.0.7são capazes de ouvi-lo.

EDIT2: Aqui estão os arquivos pcap http://filebin.net/6cle9a5iae de 10.0.0.6(módulo ZCN), 10.0.0.7(módulo ZCN) e 10.0.0.5(módulo de link TP que não tem problema). aqui estão as saídas de ping de 10.0.0.6 http://pastebin.com/swFP2CJ9. Eu capturei os pacotes simultaneamente. O link também inclui ifconfig; iwconfig; e uname- asaídas para cada nó.

Eu tive o mesmo problema recentemente. Eu descobri que os chipsets AR9271 têm problema na antena do transmissor a bordo. Se você usar uma antena externa, não terá problemas. E esse problema ocorre apenas no modo ad-hoc.

O motivo de você não ter problemas com o link TP deve ser que esses módulos usam antena externa que supera o problema do chipset, e os módulos ZCN não devem ter uma antena externa.

Isso pode estar relacionado ao " problema do nó oculto " se .6 e .7 não estiverem em contato direto com o rádio, mas sem saber as distâncias envolvidas, é impossível dizer.

Além disso, um ou ambos os chipsets podem ter um modo ad-hoc com bugs, não é muito usado atualmente e não seria surpreendente.