As respostas ARP contêm endereço MAC errado

Question

Eu tenho um robô rodando linux com adaptadores com e sem fio. Quando eu inicializo, ele se conecta à multa wireless. Quando atribuo um IP ao com fio (estaticamente ou com DHCP), parece que funciona. Como em, ifconfig mostra um IP adequado e route mostra rotas adequadas. No entanto, quando faço uma solicitação ARP do IP com fio, a resposta ARP contém o MAC sem fio.

??? Não há bridge rodando no robô, então por que eu não recebo o MAC com fio ???

Quando o fio é desconectado, o IP com fio responde ao ping ...

Por que o robô está respondendo pela interface sem fio para solicitações de IP no com fio?

EDIT: os adaptadores com e sem fio na mesma sub-rede IP. Eu faço uma solicitação ARP de um computador (tentei com computadores diferentes) na mesma sub-rede IP.

saída relevante do 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)

saída de rota 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

É um linux muito limitado, então eu não tenho ferramentas como artptables, iptables, sysctl, brctl, etc.

EDIT: diagrama conforme solicitado

EDIT:EstoujogandotráfegoeolhandoparaatabelaARP.UmasolicitaçãoARPde192.168.0.110retornaumarespostaARPcontendo24:3C:20:06:3E:6D.OMACdeorigemdopacotederespostaARPtambémé24:3C:20:06:3E:6D.Eutenteimexercom_filter,_ignoree_announce,comomencionado aqui , mas sem sucesso.

EDIT: configurar um gateway (em qualquer interface) não faz diferença (como não deveria).

EDIT: isso funcionou bem em uma versão anterior do sistema operacional (baseado em openembedded). é possível que eles mudaram alguma coisa?

    

Answer 1

O que você está vendo é um comportamento normal quando você tem duas interfaces na mesma rede. É descrito em este artigo do LWN .

    

Answer 2

Quando você diz que obtém uma resposta ARP para a interface errada, você está realmente descarregando tráfego ou apenas observando a tabela ARP resultante? É possível que você receba respostas do ARP para ambas interfaces ...

De qualquer forma, acredito que a resposta para o seu problema está na manipulação adequada de rp_filter e arp_filter . A documentação para cada um deles está incluída abaixo.

Eu sugiro primeiro tentar isso:

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

Você pode também precisa fazer essa alteração:

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

rp_filter - BOOLEAN
    1 - do source validation by reversed path, as specified in RFC1812
        Recommended option for single homed hosts and stub network
        routers. Could cause troubles for complicated (not loop free)
        networks running a slow unreliable protocol (sort of RIP),
        or using static routes.

    0 - No source validation.

    conf/all/rp_filter must also be set to TRUE to do source validation
    on the interface

    Default value is 0. Note that some distributions enable it
    in startup scripts.

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

Para um tratamento mais completo, consulte este artigo:

link

    

Answer 3

Sei que este é um problema antigo, mas recentemente encontrei a mesma situação exata com um dispositivo incorporado. O dispositivo tem uma interface ethernet e wifi e os requisitos são que ambas as interfaces possam estar ativas e na mesma rede a qualquer momento, mas o tráfego de rede deve ser roteado através da interface "preferida".

A maioria dos usuários não configuraria os dispositivos dessa maneira, mas, em teoria, isso deveria ser possível.

Primeiro, detectamos os problemas com os roteadores Netgear porque eles relatavam um conflito de endereço IP - dois endereços MAC compartilhavam um único IP. Aparentemente, o roteador começaria a se comportar mal nesse cenário e atrapalharia a rede de usuários.

Eu criei uma rede privada que continha apenas o roteador (ethernet + wifi), windows laptop (somente Ethernet) e o dispositivo incorporado (ethernet + wifi). Usando wireshark, tcpdump no dispositivo e arp no Windows, consigo ver o seguinte comportamento:

1. O ifconfig no dispositivo mostra endereços IP e IP distintos e endereços MAC distintos
2. Às vezes (muito raramente) e arp –a das janelas mostra a combinação IP-MAC correta.
3. Na maioria das vezes arp –a do windows mostra tanto o wln quanto o eth0 possuem o mesmo endereço MAC
4. Ao efetuar o ping de wln ou eth0 a partir do windows, a resposta do ping vem do wln e muito raramente da eth0. O tcpdump mostra que o wln só respondeu a 1 dos 4 pings (por exemplo)
5. Quando o windows envia uma mensagem arp “who has” para o eth0 IP - ambas as interfaces eth0 e wln responder dizendo que eles têm esse IP

Eu acredito que o item 3 é causado pelo item 5. As tabelas arp estão sendo confusas porque o wln está respondendo a mensagens arp que somente a eth0 deveria responder. Acredito que o item 4 também seja causado pelo item 5. O ping é enviado com base no endereço MAC e, como a última mensagem recebida foi do wln dizendo que possui o eth0 IP, os pings são roteados incorretamente para a interface wln.

Depois de muita escavação e testes, a solução foi realmente muito simples. Veja este artigo - link

Os drivers de rede do kernel Linux são configurados de tal forma que quando uma solicitação arp é recebida para uma interface conhecida (mesmo que seja recebida em outra interface), ela responderá ao arp.

Esta configuração resolve o problema:

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

Explicação:

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

    

Answer 4

Como isso funcionou bem em uma versão anterior do sistema operacional (baseado em openembedded), minha solução foi aguardar a próxima versão do sistema operacional. Meu melhor palpite é que o módulo do kernel sem fio estava cheio de bugs.

    

Answer 5

Continuando com o comentário de Insyte.

Vamos fazer alguns nomes:

• PC1 - Superior direito
• PC2 - superior esquerdo
• PC3 - parte inferior esquerda

Para você ter seu robô acessível a partir dos 3 PCs via mídia com e sem fio. E, por estarem na mesma sub-rede, você não pode dizer com certeza de que maneira a solicitação arp para sua mídia com fio passou. Com isso quero dizer que quando o switch transmite uma solicitação arp, seu robô o recebe nas duas interfaces [referindo-se ao seu diagrama], de modo que ele recebe a solicitação arp para o IP na mídia com fio na mídia sem fio também há chances de que ele responda com o endereço físico da mídia sem fio para que a caixa tenha esse IP configurado nela

Eu tive esse problema no passado, não foi exato para o seu, mas foi semelhante. Por padrão, o linux responde com o endereço físico da interface que recebe a solicitação arp, independentemente de qual interface o IP está configurado. Portanto, no seu caso, conecte o PC3 diretamente à interface eth0 do robô e faça um pedido arp para 192.168.0.101, ele responderia com o endereço físico da interface eth0 em vez de ra0.

Meu cenário de implantação foi:

[RTR] | ------------ eth0 --- [servidor]
     | -------- | switch1 | ----- eth1 ----- [servidor]

É o mesmo comutador ao qual ambas as interfaces se conectam. Espero que isso te ajude.

O roteador tinha endereço IP primário e secundário configurado em sua interface para duas redes diferentes nas duas interfaces diferentes no servidor. Mas recebendo um arp request na eth1 para o endereço IP da eth0 ele respondeu com o endereço físico da eth1

Para evitar isso, o seguinte já funcionou para mim

# 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

coloque-o em algum lugar no seu robô para que você possa aplicá-lo na inicialização.

Recomendações: Eu recomendo que você tenha duas sub-redes diferentes configuradas (digamos 192.168.1.x / 24 na ra0 e 192.168.2.x / 24 na eth0) você pode usar aliases de IP em seus PCs e seu robô seria acessível sobre qualquer um dos dois IPs. Você não pode ter dois caminhos de saída para a mesma sub-rede em um mesmo host. Não, a menos que haja algo que faça seu robô preferir um ao outro. Seu robô só pode pegar um caminho para enviar pacotes para fora dele.

Algumas leituras: arp_announce , arp_ignore

    

Answer 6

Eu acho que há um erro de configuração entre o AP sem fio e o seu switch. switch e AP estão ficando confusos para onde enviar pacotes. Não tenho certeza sobre isso embora. Além disso, eu acho que você deve tentar definir um gateway onde os programas podem saber para onde enviar pacotes. algo como

route add default gw 192.168.0.1