Respostas ARP contêm endereço MAC incorreto

Eu tenho um robô executando o Linux com adaptadores com e sem fio. Quando eu inicializo, ele se conecta à rede sem fio. Quando atribuo um IP ao com fio (estaticamente ou com DHCP), parece que funciona. Como ifconfigmostra , mostra um IP adequado e routemostra 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á ponte rodando no robô, então por que não consigo 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 a solicitações de IP no fio ???

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

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

saída relevante da rota:

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 reduzido, então não tenho ferramentas como artptables, iptables, sysctl, brctl, etc.

EDIT: diagrama conforme solicitado

EDIT: Estou despejando tráfego e olhando para a tabela ARP. Uma solicitação ARP de 192.168.0.110 retorna uma resposta ARP contendo 24: 3C: 20: 06: 3E: 6D. O MAC de origem do pacote de resposta ARP também é 24: 3C: 20: 06: 3E: 6D. Eu tentei mexer com _filter, _ignore e _announce, como mencionado aqui , mas sem sucesso.

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

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

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

Quando você diz que obtém uma resposta ARP para a interface incorreta, está realmente despejando tráfego ou apenas olhando para a tabela ARP resultante? É possível que você esteja recebendo respostas ARP para ambas as interfaces ...

Enfim, acredito que a resposta para o seu problema está em manipular adequadamente rp_filtere arp_filter. A documentação para cada um deles está incluída abaixo.

Sugiro primeiro tentar isso:

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

Você pode precisar fazer essa alteração, bem como:

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

rp_filter - BOOLEAN
    1 - faça a validação da fonte pelo caminho invertido, conforme especificado na RFC1812
        Opção recomendada para hosts únicos e rede stub
        roteadores. Pode causar problemas para complicados (sem loop)
        redes executando um protocolo lento e não confiável (tipo de RIP),
        ou usando rotas estáticas.

    0 - Sem validação de fonte.

    conf / all / rp_filter também deve ser definido como TRUE para fazer a validação de origem
    na interface

    O valor padrão é 0. Observe que algumas distribuições permitem
    em scripts de inicialização.

arp_filter - BOOLEAN
    1 - Permite que você tenha várias interfaces de rede no mesmo
    sub-rede e os ARPs de cada interface sejam respondidos
    com base no fato de o kernel encaminhar ou não um pacote de
    o IP ARP para fora dessa interface (portanto, você deve usar fonte
    roteamento baseado para que isso funcione). Em outras palavras, permite o controle
    dos quais cartões (normalmente 1) responderão a uma solicitação arp.

    0 - (padrão) O kernel pode responder a solicitações arp com endereços
    de outras interfaces. Isso pode parecer errado, mas geralmente faz
    sentido, porque aumenta a chance de uma comunicação bem-sucedida.
    Os endereços IP são de propriedade do host completo no Linux, não de
    interfaces particulares. Somente para configurações mais complexas, como
    balanceamento, esse comportamento causa problemas.

    O arp_filter para a interface será ativado se pelo menos um dos
    conf / {all, interface} / arp_filter está definido como TRUE,
    será desativado caso contrário

Para um tratamento mais completo, consulte este artigo:

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

Sei que esse é um problema antigo, mas recentemente encontrei exatamente a mesma situação com um dispositivo incorporado. O dispositivo possui uma interface Ethernet e Wi-Fi 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, deveria ser possível.

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

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

1. Ifconfig no dispositivo mostra IPs distintos de wln e Ethernet e endereços MAC distintos
2. Às vezes (muito raramente) e o arp –a do windows mostra a combinação IP-MAC correta.
3. Na maioria das vezes, o arp –a do windows mostra que o wln e o eth0 têm o mesmo endereço MAC
4. Ao executar ping no wln ou eth0 no Windows, a resposta do ping vem do wln e muito raramente do eth0. tcpdump mostra que o wln respondeu apenas a 1 dos 4 pings (por exemplo)
5. Quando o Windows envia uma mensagem ARP “quem possui” para o IP eth0 - as interfaces eth0 e wln respondem dizendo que possuem esse IP

Acredito que o item 3 é causado pelo item 5. As tabelas arp estão sendo alteradas porque o wln está respondendo a mensagens arp às quais apenas eth0 deve 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 arp recebida foi do wln dizendo que ele possui o IP eth0, os pings são roteados incorretamente para a interface wln.

Depois de muita pesquisa e teste, a solução era realmente muito simples. Veja este artigo - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

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

Essa 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

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

Seguindo o comentário da 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, por meio de mídia com e sem fio. E, como eles estão na mesma sub-rede, você não pode dizer com certeza de que maneira a solicitação do arp para sua mídia com fio passou. Por que o que eu quero dizer é quando as transmissões de comutação para um pedido ARP, o robô recebe em ambas as interfaces [referindo-se ao seu diagrama] assim para ele recebe a solicitação ARP para o IP na mídia com fio nos meios sem fio também chances são ele respondeu com o endereço físico da mídia sem fio da caixa que possui esse IP configurado

Eu tive esse problema no passado, não era exato para o seu, mas era semelhante. Por padrão, o linux responde com o endereço físico da interface, recebe a solicitação arp, independentemente da interface em que o IP está configurado. Portanto, no seu caso, conecte o PC3 à interface eth0 do robô diretamente e faça uma solicitação arp para 192.168.0.101. Ele responderá 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 switch, ao qual ambas as interfaces se conectam. Espero que isso ajude você.

O roteador tinha o endereço IP primário e secundário configurado em sua interface para duas redes diferentes nas duas interfaces diferentes no servidor. Mas, ao receber uma solicitação arp no eth1 para o endereço IP de eth0, ele respondeu com o endereço físico de eth1

Para impedi-lo, o seguinte até agora 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 do seu robô para que você possa aplicá-lo na inicialização.

Recomendações: eu recomendaria que você configurasse duas sub-redes diferentes (por exemplo, 192.168.1.x / 24 no ra0 e 192.168.2.x / 24 no eth0), você pode usar aliases de IP em seus PCs e seu robô estará acessível em qualquer dos dois IPs. Você não pode ter dois caminhos de saída para a mesma sub-rede em um mesmo host. A menos que exista algo que faça seu robô preferir um ao outro. Seu robô pode seguir apenas um caminho para enviar pacotes dele.

Algumas leituras: arp_announce , arp_ignore

Eu acho que há uma configuração incorreta entre o seu 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, acho que você deve tentar definir um gateway no qual os programas possam saber para onde enviar pacotes. algo como

route add default gw 192.168.0.1