15 votos

ARP respuestas contienen equivocado de dirección MAC

Tengo un robot corriendo linux con cable y adaptadores inalámbricos. Cuando arranco el sistema, éste se conecta a la inalámbricos bien. Cuando me asigna una IP a la red por cable (ya sea de forma estática o DHCP), parece que funciona. Como en, ifconfig muestra una IP correcta y route muestra adecuada de las rutas. Sin embargo, cuando hago una solicitud de ARP de la conexión IP, la respuesta de ARP que contiene la MAC inalámbrico.

??? No hay ningún puente que se ejecutan en el robot, así que ¿por qué no puedo conseguir el cable de MAC???

Cuando el cable está desconectado, el cable IP responde a ping...

¿Por qué el robot responder través de la interfaz inalámbrica para las solicitudes de propiedad intelectual en el cable???

EDIT: tanto el cable y adaptadores inalámbricos en la misma subred IP. Tengo que hacer una solicitud de ARP de un equipo (probado con diferentes equipos) en la misma subred IP.

pertinentes de la salida de ifconfig:

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)

relevantes de la ruta de salida:

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 una reducción de linux, así que no tengo herramientas como artptables, iptables, sysctl, brctl, etc.

EDIT: diagrama de como se pide

network diagram

EDIT: yo soy el dumping de tráfico y buscando en la tabla ARP. Una solicitud de ARP de 192.168.0.110 devuelve una respuesta ARP que contiene 24:3C:20:06:3E:6D. La dirección MAC de origen del paquete de respuesta ARP es también 24:3C:20:06:3E:6D. He tratado de tocar el violín con _filter, _ignore, y _announce, como se ha mencionado aquí, pero fue en vano.

EDIT: configuración de una puerta de enlace (en la interfaz) no hace ninguna diferencia (como no).

EDIT: esto funcionó bien en una versión anterior del sistema operativo (basado en openembedded). es posible que haya cambiado algo?

12voto

Kasper Holdum Puntos 4173

Lo que estamos viendo es un comportamiento normal cuando se tienen dos interfaces en la misma red. Se describe en este LWN artículo.

4voto

Tom Puntos 26

Cuando usted dice que usted consigue una respuesta de ARP para la interfaz equivocada, son en realidad de dumping, el tráfico o simplemente mirando el resultado de la tabla ARP? Es posible que usted está consiguiendo la ARP respuestas para ambas interfaces...

De todos modos, creo que la respuesta a su problema radica en la correcta manipulación rp_filter y arp_filter. La documentación para cada uno de ellos se incluye a continuación.

Sugiero que primero tratar de esto:

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

Usted puede necesitar para hacer este cambio, así:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
rp_filter - BOOLEAN
 1 - fuente de validación por invertida ruta de acceso, como se especifica en RFC1812
 Opción recomendada para un solo alojan los ejércitos y la punta de red
 los routers. Podría causar problemas complicados (bucle no libre)
 redes de ejecución de un lento poco fiables (protocolo de tipo de RIP),
 o el uso de rutas estáticas.

 0 - Ninguna fuente de validación.

 conf/all/rp_filter también se debe establecer en TRUE para hacer la validación del origen
 en la interfaz

 El valor predeterminado es 0. Tenga en cuenta que algunas distribuciones permiten
 en los scripts de inicio.

arp_filter - BOOLEAN
 1 - Permite tener varias interfaces de red en el mismo
 de subred, y tienen los Arpegios para cada interfaz de ser respondidas
 en función de si o no el núcleo de la ruta de un paquete de
 la ARP había IP que la interfaz (por lo tanto se debe utilizar la fuente
 enrutamiento basado para este trabajo). En otras palabras, permite el control de
 de que cartas (por lo general 1) responder a una solicitud de arp.

 0 - (predeterminado), El kernel puede responder a las peticiones arp con las direcciones de
 de otras interfaces. Esto puede parecer malo, pero normalmente se hace
 sentido, porque aumenta la posibilidad de éxito de la comunicación.
 Las direcciones IP son de propiedad de la completa sobre Linux, no por
 en particular interfaces. Sólo para las más complejas configuraciones como de carga
 de equilibrio, ¿ este comportamiento causar problemas.

 arp_filter para la interfaz estará habilitado si al menos uno de
 conf/{todos,interfaz}/arp_filter se establece en TRUE,
 va a ser deshabilitados

Para un tratamiento más exhaustivo, consulte este artículo:

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

4voto

undercoverMunky Puntos 11

Sé que este es un viejo tema, pero hace poco me encontré exactamente la misma situación con un dispositivo embebido. El dispositivo tiene una conexión ethernet y wifi interfaz y los requisitos son que ambas interfaces pueden ser activos y en la misma red en cualquier momento, pero el tráfico de la red debe ser enrutado a través de los "preferidos" de la interfaz.

La mayoría de los usuarios no configurar los dispositivos de esta manera, pero en teoría debería ser posible.

Nos tomó por primera vez los problemas con los routers de Netgear porque el informe de un conflicto de Direcciones IP - 2 direcciones MAC estaban compartiendo una única dirección IP. Al parecer el router sería empezar a comportarse mal en este escenario y desordenar los usuarios de la red.

He creado una red privada que sólo contenía el router (ethernet + wifi), un ordenador portátil de windows (Ethernet), y el dispositivo incorporado (ethernet + wifi). El uso de wireshark, tcpdump en el dispositivo, y arp en windows puedo ver el siguiente comportamiento:

  1. Ifconfig en el dispositivo muestra diferentes wln y Ethernet IP y distintas direcciones MAC
  2. A veces (muy rara vez) y arp –a partir de windows muestra la IP-MAC combinación.
  3. La mayoría del tiempo arp –a partir de windows, se muestra tanto la wln y eth0 tienen la misma dirección MAC
  4. Al hacer ping a cualquiera de wln o eth0 de windows, la respuesta al ping viene de wln y muy rara vez de eth0. tcpdump muestra la wln sólo respondió a 1 de los 4 pings (por ejemplo)
  5. Cuando windows envía un arp", que ha" mensaje para la eth0 IP – tanto la eth0 y wln interfaces responder diciendo que tiene esa IP

Creo que el punto 3 es causada por el punto 5. Las tablas arp están en mal estado debido a la wln es responder a los mensajes arp que sólo eth0 debe responder. Creo que el punto 4 también es causada por el punto 5. Ping es enviado basado en la dirección MAC y desde la última arp mensaje recibido fue de wln diciendo que tiene la eth0 IP, los pings son enviados incorrectamente a la wln de la interfaz.

Después de mucho excavación y pruebas de la solución fue muy simple. Ver este artículo http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

El kernel de Linux controladores de red están configurados de tal manera que cuando una solicitud de arp es recibido por un conocido de la interfaz (incluso si se recibe en otra interfaz) que responda a la arp.

Esta configuración se 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

1voto

Jayen Puntos 448

Como esta funcionado bien en una versión anterior del sistema operativo (basado en openembedded), mi solución era esperar a la próxima versión del sistema operativo. Mi mejor conjetura es que la inalámbrica módulo del kernel que era defectuoso.

0voto

Gaumire Puntos 790

El seguimiento de Insyte del comentario.

Hagamos algunas de nomenclatura:

  • PC1 - Arriba a la Derecha
  • PC2 - Arriba a la Izquierda
  • PC3 - Abajo a la Izquierda

Para que usted tenga su robot accesible desde el 3 de Pc a través de cable e inalámbricas de los medios de comunicación. Y para los que están en la misma subred que no seguro decir que la manera en la que la solicitud de arp para su cable de medios de comunicación ha pasado. Por que lo que quiero decir es que cuando el interruptor de emisiones para una solicitud de arp, el robot recibe tanto en las interfaces [refiriéndose a su diagrama] así que para que reciba la solicitud arp para la dirección IP en el cable de los medios de comunicación en los medios de comunicación inalámbrico también es probable que respondió con la dirección física de la red inalámbrica, los medios de comunicación para la caja tiene la IP configurada en ella

He tenido este problema en el pasado, no era exacta a la suya, pero fue similar. Por defecto de linux responde con la dirección física de la interfaz que recibe la solicitud de arp, independientemente de que la interfaz del IP está configurado en. Así que, en su caso, conecte PC3 para el robot de la interfaz eth0 directamente y hacer una solicitud de arp para 192.168.0.101 se le responde con la dirección física de la interfaz eth0 en lugar de ra0.

Mi escenario de implementación fue:

[RTR] |------------eth0---[server]
|--------| conmutador1 |----- eth1-----[server]

Su mismo interruptor, que ambas interfaces conectar. La esperanza de que le sería de ayuda.

El router principal y secundaria de la dirección IP configurada en su interfaz para dos redes diferentes en los dos tipos de interfaces en el servidor. Pero la recepción de una solicitud de arp en eth1 para la dirección IP de eth0 lo hizo de respuesta con la dirección física de eth1

Para evitar que los siguientes que hasta ahora ha funcionado para mí

# 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

ponerlo en algún lugar en su robot, así que usted puede conseguir ser aplicado en el arranque.

Recomendaciones: yo recomendaría que usted tiene dos subredes diferentes configurarse (decir 192.168.1.x/24 en ra0 y 192.168.2.x/24 de eth0) puede utilizar alias de IP en su Pc y el robot sería accesible a través de cualquiera de las dos IPs. Usted no puede tener dos caminos salientes para la misma subred en un mismo host. No, a menos que hay algo que hace que su robot preferir una sobre otra. El robot puede tomar un único camino para enviar paquetes fuera de él.

Algunas lecturas: arp_announce, arp_ignore

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: