Las respuestas ARP contienen una dirección MAC incorrecta

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?

Lo que está viendo es un comportamiento normal cuando tiene dos interfaces en la misma red. Se describe en este artículo de LWN .

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_filtery arp_filter. La documentación para cada uno de ellos se incluye a continuación.

Sugiero primero intentar esto:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Es posible que también necesite hacer este cambio:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

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 contrario

Para un tratamiento más completo, vea este artículo:

http://www.embedded-bits.co.uk/tag/rp_filter/

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:

1. Ifconfig en el dispositivo muestra distintos wln e IP de Ethernet y distintas direcciones MAC
2. A veces (muy raramente) y arp –a de windows muestra la combinación correcta de IP-MAC.
3. La mayoría de las veces, arp –a from windows muestra que tanto wln como eth0 tienen la misma dirección MAC
4. Al hacer ping a wln o eth0 desde windows, la respuesta de ping proviene de wln y muy raramente de eth0. tcpdump muestra que el wln solo respondió a 1 de los 4 pings (por ejemplo)
5. Cuando Windows envía un mensaje de "quién tiene" arp para la IP eth0, las interfaces eth0 y wln responden diciendo que tienen esa IP

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_ignore

Explicación:

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied

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.

Siguiendo el comentario de Insyte.

Hagamos algunos nombres:

• PC1 - Arriba a la derecha
• PC2 - Superior izquierda
• PC3 - Abajo a la izquierda

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

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

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

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.1