Le risposte ARP contengono un indirizzo MAC errato

Ho un robot che esegue Linux con adattatori cablati e wireless. Quando avvio, si collega alla multa wireless. Quando assegno un IP al cavo (staticamente o con DHCP), sembra che funzioni. Come in, ifconfigmostra un IP corretto e routemostra i percorsi corretti. Tuttavia, quando eseguo una richiesta ARP dell'IP cablato, la risposta ARP contiene il MAC wireless.

??? Non c'è alcun ponte in esecuzione sul robot, quindi perché non ottengo il MAC cablato ???

Quando il cavo viene disconnesso, l'IP cablato risponde al ping ...

Perché il robot risponde tramite l'interfaccia wireless alle richieste IP sul cavo ???

EDIT: sia gli adattatori cablati che wireless sulla stessa sottorete IP. Eseguo una richiesta ARP da un computer (provato con computer diversi) sulla stessa sottorete IP.

output ifconfig rilevante:

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)

uscita del percorso pertinente:

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

È un Linux molto ridotto, quindi non ho strumenti come artptables, iptables, sysctl, brctl, ecc.

MODIFICA: diagramma come richiesto

EDIT: sto scaricando il traffico e guardando il tavolo ARP. Una richiesta ARP di 192.168.0.110 restituisce una risposta ARP contenente 24: 3C: 20: 06: 3E: 6D. Il MAC sorgente del pacchetto di risposta ARP è anche 24: 3C: 20: 06: 3E: 6D. Ho provato a giocherellare con _filter, _ignore e _announce, come menzionato qui , ma senza risultati.

EDIT: l'impostazione di un gateway (su entrambe le interfacce) non fa differenza (come non dovrebbe).

EDIT: funzionava bene su una versione precedente del sistema operativo (basato su openembedded). è possibile che abbiano cambiato qualcosa?

Quello che vedi è un comportamento normale quando hai due interfacce sulla stessa rete. È descritto in questo articolo LWN .

Quando dici di avere una risposta ARP per l'interfaccia sbagliata, stai effettivamente scaricando il traffico o stai solo guardando la tabella ARP risultante? È possibile che tu stia ricevendo risposte ARP per entrambe le interfacce ...

Comunque, credo che la risposta al tuo problema risieda nella corretta manipolazione rp_filtere arp_filter. La documentazione per ciascuno di essi è inclusa di seguito.

Suggerisco prima di provare questo:

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

Si potrebbe essere necessario effettuare questa modifica così:

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

rp_filter - BOOLEAN
    1 - esegue la convalida della sorgente tramite percorso inverso, come specificato in RFC1812
        Opzione consigliata per host a casa singola e rete di stub
        router. Potrebbe causare problemi per complicati (non senza loop)
        reti che eseguono un protocollo lento inaffidabile (sorta di RIP),
        o usando percorsi statici.

    0 - Nessuna convalida della fonte.

    conf / all / rp_filter deve anche essere impostato su TRUE per eseguire la convalida del codice sorgente
    sull'interfaccia

    Il valore predefinito è 0. Nota che alcune distribuzioni lo abilitano
    negli script di avvio.

arp_filter - BOOLEAN
    1 - Consente di avere più interfacce di rete sullo stesso
    sottorete e ottenere risposta agli ARP per ciascuna interfaccia
    in base al fatto che il kernel instradi o meno un pacchetto
    l'IPP ha fatto uscire quell'interfaccia (quindi è necessario utilizzare il sorgente
    instradamento basato per farlo funzionare). In altre parole, consente il controllo
    di quali carte (di solito 1) risponderanno a una richiesta arp.

    0 - (impostazione predefinita) Il kernel può rispondere alle richieste arp con indirizzi
    da altre interfacce. Questo può sembrare sbagliato ma di solito lo fa
    senso, perché aumenta le possibilità di comunicazione riuscita.
    Gli indirizzi IP sono di proprietà dell'host completo su Linux, non di
    interfacce particolari. Solo per configurazioni più complesse come load-
    bilanciamento, questo comportamento causa problemi.

    arp_filter per l'interfaccia sarà abilitato se almeno uno di
    conf / {all, interface} / arp_filter è impostato su TRUE,
    altrimenti verrà disabilitato

Per un trattamento più approfondito, vedi questo articolo:

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

So che questo è un vecchio problema, ma di recente ho riscontrato la stessa identica situazione con un dispositivo incorporato. Il dispositivo ha un'interfaccia ethernet e wifi e i requisiti sono che entrambe le interfacce possano essere attive e sulla stessa rete in qualsiasi momento, ma il traffico di rete deve essere instradato attraverso l'interfaccia "preferita".

La maggior parte degli utenti non configurerebbe i dispositivi in ​​questo modo, ma in teoria dovrebbe essere possibile.

Per prima cosa abbiamo riscontrato i problemi con i router Netgear perché avrebbero segnalato un conflitto di indirizzi IP: 2 indirizzi MAC condividevano un singolo IP. Apparentemente il router avrebbe iniziato a comportarsi male in questo scenario e avrebbe incasinato la rete degli utenti.

Ho creato una rete privata che conteneva solo il router (ethernet + wifi), laptop Windows (solo Ethernet) e il dispositivo incorporato (ethernet + wifi). Utilizzando WireShark, tcpdump sul dispositivo e ARP su Windows posso vedere il seguente comportamento:

1. Ifconfig sul dispositivo mostra IP wln ed Ethernet distinti e indirizzi MAC distinti
2. A volte (molto raramente) e arp –a da Windows mostra la corretta combinazione IP-MAC.
3. Il più delle volte arp –a da windows mostra che sia wln che eth0 hanno lo stesso indirizzo MAC
4. Quando si esegue il ping di wln o eth0 da Windows, la risposta del ping proviene da wln e molto raramente da eth0. tcpdump mostra che il wln ha risposto solo a 1 dei 4 ping (ad esempio)
5. Quando windows invia un messaggio arp "who have" per l'IP eth0 - entrambe le interfacce eth0 e wln rispondono dicendo che hanno quell'IP

Credo che l'articolo 3 sia causato dall'articolo 5. Le tabelle arp sono incasinate perché wln sta rispondendo a messaggi arp a cui solo eth0 dovrebbe rispondere. Credo che anche l'articolo 4 sia causato dall'articolo 5. Il ping viene inviato in base all'indirizzo MAC e poiché l'ultimo messaggio arp ricevuto è stato da wln dicendo che ha l'IP eth0, i ping vengono indirizzati in modo errato all'interfaccia wln.

Dopo aver scavato e testato molto, la soluzione era in realtà molto semplice. Vedi questo articolo - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

I driver di rete del kernel Linux sono configurati in modo tale che quando viene ricevuta una richiesta arp per un'interfaccia nota (anche se ricevuta su un'altra interfaccia) risponderà all'arp.

Questa impostazione risolve il problema:

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

Spiegazione:

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

Dato che funzionava bene su una versione precedente del sistema operativo (basata su openembedded), la mia soluzione era di attendere la versione successiva del sistema operativo. La mia ipotesi migliore era che il modulo del kernel wireless fosse difettoso.

In seguito al commento di Insyte.

Facciamo un po 'di denominazione:

• PC1 - In alto a destra
• PC2 - In alto a sinistra
• PC3 - In basso a sinistra

Perché il tuo robot è raggiungibile dai 3 PC tramite media cablati e wireless. E poiché si trovano sulla stessa sottorete, non si può sicuramente dire in che modo è passata la richiesta arp per il proprio media cablato. Con questo quello che voglio dire è quando le trasmissioni switch per una richiesta ARP, il robot riceve da entrambi le interfacce [riferendosi al diagramma] in modo per esso riceve la richiesta ARP per l'IP sui media cablati sui supporti senza fili anche le probabilità sono ha risposto con l'indirizzo fisico del supporto wireless per la casella in cui è configurato l'IP

Ho avuto questo problema in passato, non era esatto per il tuo ma era simile. Di default linux risponde con l'indirizzo fisico dell'interfaccia che riceve la richiesta arp indipendentemente dall'interfaccia su cui è configurato l'IP. Quindi nel tuo caso collega direttamente PC3 all'interfaccia eth0 del robot ed esegui una richiesta arp per 192.168.0.101 ti risponderebbe con l'indirizzo fisico dell'interfaccia eth0 anziché ra0.

Il mio scenario di distribuzione era:

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

È lo stesso interruttore a cui si collegano entrambe le interfacce. Spero che ti possa aiutare.

Il router aveva un indirizzo IP primario e secondario configurato sulla sua interfaccia per due diverse reti sulle due diverse interfacce sul server. Ma ricevere una richiesta arp su eth1 per l'indirizzo IP di eth0 ha risposto con l'indirizzo fisico di eth1

Per evitarlo, finora ha funzionato per me

# 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

mettilo da qualche parte sul tuo robot in modo da poterlo applicare all'avvio.

Raccomandazioni: ti consiglio di configurare due diverse sottoreti (diciamo 192.168.1.x / 24 su ra0 e 192.168.2.x / 24 su eth0), puoi usare gli alias IP sui tuoi PC e il tuo robot sarebbe accessibile su qualsiasi dei due IP. Non è possibile avere due percorsi in uscita per la stessa sottorete su uno stesso host. A meno che non ci sia qualcosa che fa preferire il tuo robot l'uno all'altro. Il tuo robot può percorrere solo un percorso per inviarne i pacchetti.

Alcune letture: arp_announce , arp_ignore

penso che ci sia una configurazione errata tra il tuo AP wireless e il tuo switch. switch e AP si stanno confondendo su dove inviare i pacchetti. non sono sicuro di questo però. inoltre, penso che dovresti provare a definire un gateway in cui i programmi possano sapere dove inviare i pacchetti. qualcosa di simile a

route add default gw 192.168.0.1