Tengo un robot que ejecuta Linux con adaptadores cableados e inalámbricos. Cuando inicio, se conecta a la multa inalámbrica. Cuando asigno una IP al cable (estáticamente o con DHCP), parece que funciona. Como en, ifconfigmuestra una IP adecuada y routemuestra las rutas adecuadas. Sin embargo, cuando hago una solicitud ARP de la IP cableada, la respuesta ARP contiene el MAC inalámbrico.
??? No hay un puente que se ejecute en el robot, ¿por qué no obtengo el MAC con cable?
Cuando se desconecta el cable, la IP cableada responde al ping ...
¿Por qué el robot responde a través de la interfaz inalámbrica a las solicitudes de IP en el cable?
EDITAR: tanto los adaptadores con cable como los inalámbricos en la misma subred IP. Hago una solicitud ARP desde una computadora (probado con diferentes computadoras) en la misma subred IP.
salida ifconfig relevante:
eth0 Link encap:Ethernet HWaddr 00:01:C0:04:BD:F7
inet addr:192.168.0.110 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ra0 Link encap:Ethernet HWaddr 24:3C:20:06:3E:6D
inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:59 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:31023598 (29.5 MiB) TX bytes:85640627 (81.6 MiB)
salida de ruta relevante:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Es un Linux muy reducido, así que no tengo herramientas como artptables, iptables, sysctl, brctl, etc.
EDITAR: diagrama según lo solicitado
EDITAR: estoy volcando el tráfico y mirando la tabla ARP. Una solicitud ARP de 192.168.0.110 devuelve una respuesta ARP que contiene 24: 3C: 20: 06: 3E: 6D. La fuente MAC del paquete de respuesta ARP también es 24: 3C: 20: 06: 3E: 6D. He intentado jugar con _filter, _ignore y _announce, como se mencionó aquí , pero fue en vano.
EDITAR: configurar una puerta de enlace (en cualquier interfaz) no hace ninguna diferencia (como no debería).
EDITAR: esto funcionó bien en una versión anterior del sistema operativo (basado en openembedded). ¿Es posible que hayan cambiado algo?
Respuestas:
Lo que está viendo es un comportamiento normal cuando tiene dos interfaces en la misma red. Se describe en este artículo de LWN .
fuente
Cuando dice que obtiene una respuesta ARP para la interfaz incorrecta, ¿está realmente volcando el tráfico o simplemente mirando la tabla ARP resultante? Es posible que obtenga respuestas ARP para ambas interfaces ...
De todos modos, creo que la respuesta a su problema radica en manipular adecuadamente
rp_filteryarp_filter. La documentación para cada uno de ellos se incluye a continuación.Sugiero primero intentar esto:
Es posible que también necesite hacer este cambio:
rp_filter - BOOLEAN 1 - haga la validación de la fuente por ruta invertida, como se especifica en RFC1812 Opción recomendada para hosts únicos alojados y red stub enrutadores Podría causar problemas para complicados (no sin bucle) redes que ejecutan un protocolo lento y poco confiable (tipo de RIP), o usando rutas estáticas. 0: sin validación de origen. conf / all / rp_filter también debe establecerse en TRUE para hacer la validación de la fuente en la interfaz El valor predeterminado es 0. Tenga en cuenta que algunas distribuciones lo permiten en guiones de inicio. arp_filter - BOOLEAN 1 - Le permite tener múltiples interfaces de red en el mismo subred, y que se respondan los ARP para cada interfaz en función de si el núcleo enrutará o no un paquete desde la IP ARP'd de esa interfaz (por lo tanto, debe usar la fuente enrutamiento basado para que esto funcione). En otras palabras, permite el control. de las cuales las tarjetas (generalmente 1) responderán a una solicitud de arp. 0 - (predeterminado) El núcleo puede responder a solicitudes arp con direcciones desde otras interfaces. Esto puede parecer incorrecto, pero generalmente hace sentido, porque aumenta la posibilidad de una comunicación exitosa. Las direcciones IP son propiedad del host completo en Linux, no de interfaces particulares Solo para configuraciones más complejas como load- equilibrando, este comportamiento causa problemas. arp_filter para la interfaz se habilitará si al menos uno de conf / {all, interface} / arp_filter está establecido en TRUE, se desactivará de lo contrarioPara un tratamiento más completo, vea este artículo:
http://www.embedded-bits.co.uk/tag/rp_filter/
fuente
Sé que este es un problema antiguo, pero recientemente encontré exactamente la misma situación con un dispositivo incorporado. El dispositivo tiene una interfaz de ethernet y wifi y los requisitos son que ambas interfaces puedan estar activas y en la misma red en cualquier momento, pero el tráfico de red debe enrutarse a través de la interfaz "preferida".
La mayoría de los usuarios no configurarían sus dispositivos de esta manera, pero en teoría debería ser posible.
Primero abordamos los problemas con los enrutadores Netgear porque informaban un conflicto de dirección IP: 2 direcciones MAC compartían una sola IP. Aparentemente, el enrutador comenzaría a comportarse mal en este escenario y dañaría la red de los usuarios.
Creé una red privada que solo contenía el enrutador (ethernet + wifi), la computadora portátil windows (solo Ethernet) y el dispositivo integrado (ethernet + wifi). Usando wireshark, tcpdump en el dispositivo y arp en Windows, puedo ver el siguiente comportamiento:
Creo que el elemento 3 es causado por el elemento 5. Las tablas arp se están desordenando porque el wln está respondiendo a los mensajes arp a los que solo eth0 debería responder. Creo que el elemento 4 también es causado por el elemento 5. Ping se envía en función de la dirección MAC y, dado que el último mensaje arp recibido fue de wln diciendo que tiene el eth0 IP, los pings se enrutan incorrectamente a la interfaz wln.
Después de mucho excavar y probar, la solución fue realmente simple. Ver este artículo: http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html
Los controladores de red del kernel de Linux están configurados de tal manera que cuando se recibe una solicitud arp para una interfaz conocida (incluso si se recibe en otra interfaz) responderá al arp.
Esta configuración resuelve el problema:
echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignoreExplicación:
fuente
Como esto funcionó bien en una versión anterior del sistema operativo (basado en openembedded), mi solución fue esperar la próxima versión del sistema operativo. Mi mejor suposición fue que el módulo del kernel inalámbrico tenía errores.
fuente
Siguiendo el comentario de Insyte.
Hagamos algunos nombres:
Para que tenga su robot accesible desde las 3 PC a través de medios cableados e inalámbricos. Y dado que están en la misma subred, no se puede decir con certeza de qué manera se ha enviado la solicitud de ARP para sus medios cableados. Por eso lo que quiero decir es que cuando las transmisiones de conmutación para una solicitud ARP, el robot recibe en las interfaces [refiriéndose al diagrama] por lo que para que reciba la solicitud ARP para la dirección IP en los medios cableados en los medios de comunicación inalámbricos también lo más probable es respondió con la dirección física de los medios inalámbricos porque la caja tiene esa IP configurada
He tenido este problema en el pasado, no era exacto al tuyo, pero era similar. De manera predeterminada, Linux responde con la dirección física de la interfaz en la que recibe la solicitud arp, independientemente de la interfaz en la que esté configurada la IP. Entonces, en su caso, conecte PC3 a la interfaz eth0 del robot directamente y haga una solicitud arp para 192.168.0.101, le respondería con la dirección física de la interfaz eth0 en lugar de ra0.
Mi escenario de implementación fue:
[RTR] | ------------ eth0 --- [servidor]
| -------- | switch1 | ----- eth1 ----- [servidor]
Es el mismo conmutador al que se conectan ambas interfaces. Espero que te ayude.
El enrutador tenía una dirección IP primaria y secundaria configurada en su interfaz para dos redes diferentes en las dos interfaces diferentes del servidor. Pero al recibir una solicitud arp en eth1 para la dirección IP de eth0, respondió con la dirección física de eth1
Para evitarlo, lo siguiente me ha funcionado hasta ahora
colóquelo en algún lugar de su robot para que pueda aplicarlo en el arranque.
Recomendaciones: recomendaría que se configuraran dos subredes diferentes (por ejemplo, 192.168.1.x / 24 en ra0 y 192.168.2.x / 24 en eth0) puede usar alias de IP en sus PC y su robot sería accesible desde cualquier de las dos IP. No puede tener dos rutas de salida para la misma subred en un mismo host. No, a menos que haya algo que haga que tu robot prefiera uno sobre otro. Su robot solo puede tomar una ruta para enviar paquetes.
Algunas lecturas: arp_announce , arp_ignore
fuente
Creo que hay una mala configuración entre su AP inalámbrico y su conmutador. switch y AP se están confundiendo a dónde enviar paquetes. Aunque no estoy seguro de esto. Además, creo que debería intentar definir una puerta de enlace donde los programas puedan saber dónde enviar paquetes. algo como
route add default gw 192.168.0.1fuente