arp-requests não pode ser visto por nós específicos

12

Eu crio um wlan ad-hoc aberto usando iwconfig (também tenho o mesmo problema com wpa_supplicant ). Existem 4 nós na rede, como visto na figura abaixo. Os nodos executam o Ubuntu 12.04 e o debian squeeze, e possuem os kernels 3.7.1, 3.5 e 3.2. Eu uso duas marcas diferentes de dongle USB (link TP e ZCN) que têm chipset AR9271 e ath9k_htc driver (aqui é saída lsusb e < href="http://pastebin.com/K8LMaciz"> saída ethtool ).

O problema que estou enfrentando é que dois nós ( 10.0.0.2 e 10.0.0.5 ) que têm dongles wifi usb TP link podem pingar qualquer nó na rede e vice-versa. No entanto, os outros nós ( 10.0.0.6 e 10.0.0.7 ) que têm dongle ZCN wifi não podem pingar uns aos outros, mas eles não têm problema em se comunicar com os módulos wifi TP-link. tcpdump mostra que 10.0.0.6 e 10.0.0.7 não conseguem 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 do 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 pela qual 10.0.0.6 e 10.0.0.7 não podem ver o arp-request que eles enviam um ao outro? Como posso descobrir o problema?

Se eu adicionar mais nós com o dongle ZCN wifi na rede, esses nós também não poderão falar uns com os outros, mas eles estão bem com o TP-link. Ou, se eu trocar os módulos wifi, os nós com ZCN sempre terão problemas, mas os módulos TP-link estão bem.

aqui é o /etc/network/interfaces , ifconfig , iwconfig , ip a , ip r , route outputs

EDIT: Eu estava suspeitando se o problema é arp_filter relacionado, mas /proc/sys/net/ipv4/conf/*/arp_filter é 0 em todos os subdomínios (*). Se eu adicionar informações de arp de 10.0.0.6 e 10.0.0.7 manualmente nesses nós, tcpdump e wireshark não mostrarão que eles enviam ping um para o outro. Se eu ping o endereço de broadcast (10.0.0.255 no meu caso), 10.0.0.6 e 10.0.0.7 poderão ouvi-lo.

EDIT2: Aqui estão os arquivos pcap link de 10.0.0.6 (módulo ZCN), 10.0.0.7 (módulo ZCN) e 10.0.0.5 (Módulo TP-link que não tem problema). aqui estão as saídas de ping do 10.0.0.6 link Eu capturei os pacotes simultaneamente. O link também inclui ifconfig ; %código%; e iwconfig de saídas para cada nó.

    
por johan 26.03.2013 / 20:49

2 respostas

1

Eu tive o mesmo problema recentemente. Eu descobri que o chipset AR9271 tem problema na antena do transmissor onboard. Se você usar uma antena externa, não terá um problema. E esse problema só ocorre no modo ad-hoc.

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

    
por 05.07.2013 / 01:07
1

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

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

    
por 12.05.2013 / 10:40