Tengo una red de puntos de acceso inalámbrico (AP) en mi red de área local (LAN).
Algunas PC de la red pueden obtener respuestas de ping de otras PC/dispositivos de la red, pero no de otros. No he encontrado un patrón confiable pero en resumen puede ser algo como esto:
Digamos que tenemos una computadora Alice, un AP Wifi Bob y otro AP/dispositivo Wifi Charlie.
Alice puede hacer ping a Bob, Bob puede hacer ping a Charlie, pero Alice no puede hacer ping a Charlie. ("ping" significa poder obtener respuestas de ping) Ya deshabilité todos los firewalls y permití todas las respuestas ICMP.
Con la ayuda de Wireshark y tcpdump, deduje que el paquete de solicitud ARP (código de operación 1) de Alice pudo llegar al destino previsto, Charlie, y Charlie envió de vuelta el paquete de respuesta ARP (código de operación 2) que no llegó a Alice.
¿Cuáles podrían ser las posibles deficiencias técnicas que provocan tal error?
¿Cómo puedo depurar esta situación?
Suponiendo que tengo cierto control programático porque estoy usando OpenWRT, ¿cómo puedo resolver este problema?
Lo curioso es que cuando cambié el nombre de mi PC con Windows 8, este problema se solucionó. No estoy seguro de si se trata de un caso post hoc ergo propter hoc.
Actualización: Los AP/dispositivos/PC están en la misma subred, vinculados mediante el modo puente.
Respuesta1
Si bien no estoy muy familiarizado con la configuración avanzada en OpenWRT (está en mi lista de tareas pendientes para proyectos geek), mi primer consejo sería asegurarte de que no estás haciendo NAT en "Bob". Si Alice estuviera en el lado LAN de un WAP y Charlie estuviera en el lado WAN, entonces Alice podría hacer ping a Charlie, pero no al revés. Ese es el firewall inherente que proporciona NAT.
Para que este no sea el caso, todos sus AP deben estar funcionando en algún tipo de modo "puente" o modo "punto de acceso". Esto significa que el dispositivo actúa más o menos como un reenviador de paquetes: no realiza ningún enrutamiento ni inspección de paquetes por sí solo. La forma más sencilla de lograr esto en enrutadores más económicos es desactivar el servidor DHCP en el enrutador y luego conectar uno de los puertos LAN a su red (y también asegurarse de que la IP LAN del enrutador no entre en conflicto con su puerta de enlace real). Dejarías el puerto WAN colgado. Si el enrutador se queja (la mayoría no, pero algunos sí), configure la conexión a Internet en una IP estática y use algo como 223.255.255.254 con una máscara de subred 255.255.255.252 para la dirección y 223.255.255.253 para la puerta de enlace. (Trivia: esa es la última subred de Clase C del tamaño más pequeño posible).
La otra posibilidad podría ser una discrepancia en la máscara de subred. Cada computadora en la misma red debe tener configurada la misma máscara de subred (además de estar en la misma red real, por supuesto). La computadora usa la máscara de subred para determinar no solo la dirección de transmisión IP sino también para determinar si los paquetes de transmisión recibidos deben ser procesado por la pila de red (es decir, si se transmiten paquetes para IP que quedarían fuera de la dirección y máscara de subred configuradas en el dispositivo, muchos dispositivos ignorarán el paquete).
Espero que esto ayude al menos un poco.
Respuesta2
¿Qué causa la caída de paquetes de respuesta ARP en una red inalámbrica?
Nada. Si estuviéramos presenciando una caída adecuada de paquetes, no habría ninguna razón para que se descarten preferentemente. En presencia de una línea de comunicación defectuosa, los paquetes ARP no son diferentes de UDP, TCP y demás. Pero, dado que usted no afirma que la línea sea lenta, no hay ninguna razón real para sospechar una verdadera caída de paquetes.
La razón por la que los paquetes no llegan al destino previsto es que no se enrutan correctamente. Sin embargo, ha señalado que los paquetes que están desapareciendo mágicamente son paquetes ARP, que no necesitan un enrutamiento adecuado porque llenan espontáneamente toda la subred a la que pertenecen.
Por lo tanto, las PC son (muy probablemente) miembros de dos subredes diferentes. Los paquetes ARP no cruzan puertas de enlace y una de las razones para que lo haganabandonóes que llenan su propia subred, no encuentran ningún encuestado y luego desaparecen sin cruzar la puerta de enlace que separa las dos subredes diferentes.
La pertenencia a dos subredes separadas quedaría enmascarada, por así decirlo, si utilizara nombres en lugar de direcciones IP. Si, en cambio, utilizara direcciones IP, se habría dado cuenta inmediatamente de que las dos computadoras están en subredes diferentes. De ahí mi pregunta anterior.
¿Puedes solucionar este problema? Por supuesto que puede. Tendrá que identificar la puerta de enlace de la subred a la que no se puede acceder (llamémosla G2), permitir que las conexiones entren desde la LAN más grande y luego indicarle a la puerta de enlace de toda su LAN (G1, la que está inmediatamente detrás de su módem, o su enrutador ADSL, cualquiera) que la ruta a esta subred no es a través de sí mismo, G1, sino a través de G2.