las solicitudes arp no pueden ser vistas por nodos específicos


12

Creo un wlan ad-hoc abierto mediante el uso iwconfig(también tengo el mismo problema wpa_supplicant). Hay 4 nodos en la red como se ve en la figura a continuación. Los nodos ejecutan ubuntu 12.04 y debian squeeze, y tienen núcleos 3.7.1, 3.5 y 3.2. Uso dos marcas de dongle usb diferentes (TP link y ZCN) que tienen un conjunto de chips AR9271 y un ath9k_htccontrolador (aquí hay salida lsusb y salida ethtool ).

El problema que estoy experimentando es que dos nodos ( 10.0.0.2y 10.0.0.5) que tienen dongles wifi usb de enlace TP pueden hacer ping a cualquier nodo en la red, y viceversa. Sin embargo, los otros nodos ( 10.0.0.6y 10.0.0.7) que tienen dongle wifi ZCN no pueden hacer ping entre sí, pero no tienen problemas para comunicarse con los módulos wifi TP-link. tcpdumpmuestra eso 10.0.0.6y 10.0.0.7no puede ver su solicitud arp, por ejemplo

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

pero pueden ver y obtener respuestas de los módulos 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

Mi pregunta es: ¿cuál podría ser la razón 10.0.0.6y 10.0.0.7no puedo ver lo arp-requestque se envían? ¿Cómo puedo averiguar el problema?

Si agrego un par más de nodos con el dongle wifi ZCN en la red, estos nodos tampoco podrán comunicarse entre sí, pero están bien con TP-link. O si cambio los módulos wifi, los nodos con ZCN siempre tienen problemas, pero los módulos TP-link están bien. ingrese la descripción de la imagen aquí

aquí es los /etc/network/interfaces, ifconfig, iwconfig, ip a, ip r, routesalidas

EDITAR: sospechaba si el problema está arp_filterrelacionado pero /proc/sys/net/ipv4/conf/*/arp_filterestá 0en todos los subdominios (*). Si agrego información de arp 10.0.0.6y 10.0.0.7manualmente en estos nodos, tcpdumpy wiresharkno muestra que se envían pingentre sí. Si tengo pingla dirección de transmisión (10.0.0.255 en mi caso), 10.0.0.6y 10.0.0.7puedo escucharla.

EDIT2: Aquí hay archivos pcap http://filebin.net/6cle9a5iae de 10.0.0.6(módulo ZCN), 10.0.0.7(módulo ZCN) y 10.0.0.5(módulo TP-link que no tiene problema). Aquí están las salidas de ping de 10.0.0.6 http://pastebin.com/swFP2CJ9 Capturé los paquetes simultáneamente. El enlace también incluye ifconfig; iwconfig; y uname- asalidas para cada nodo.


¿Puede hacer una captura de red del tráfico ARP en las máquinas 10.0.0.6 y 10.0.0.7 al mismo tiempo? Use tcp dump y compártalo como un archivo pcap.
Mircea Vutcovici

Gracias Mircea Vutcovici, por favor vea el EDIT2 para los archivos pcap. Avíseme si desea obtener más información.
johan

Bueno, puede intentar usar ARP estático y ver cómo / si cambia el problema de conectividad.
poige

¿Podría publicar un volcado del tráfico de una herramienta sniffer inalámbrica como kismet? Esto incluirá los encabezados 802.11 en caso de que haya algo extraño en ellos.
Flup

2
dados los problemas que está teniendo con los dongles ZCN, y su requisito de que todos los clientes hablen directamente entre ellos en la red, simplemente los descartaría y los reemplazaría con los dongles TPLink que realmente funcionan en su red. O podría ser un problema de controlador con los adaptadores ZCN; pruebe con otro.
Agosto

Respuestas:


1

Tuve el mismo problema recientemente. Descubrí que el chipset AR9271 tiene un problema en la antena del transmisor a bordo. Si usa una antena externa, no tendrá ningún problema. Y este problema solo ocurre en modo ad-hoc.

La razón por la que no tiene problemas con el TP-link debería ser que estos módulos usan una antena externa que supera el problema del chipset, y los módulos ZCN no deberían tener una antena externa.


1

Esto podría estar relacionado con el " problema del nodo oculto " si .6 y .7 no están en contacto directo por radio, pero sin conocer las distancias involucradas es imposible decirlo.

Además, uno o ambos conjuntos de chips podrían tener un modo ad hoc con errores, no se usa mucho en estos días y no sería sorprendente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.