Odpowiedzi ARP zawierają nieprawidłowy adres MAC

Mam robota z systemem Linux z adapterami przewodowymi i bezprzewodowymi. Po uruchomieniu łączy się z bezprzewodową funkcją grzywny. Kiedy przypisuję adres IP przewodowemu (statycznie lub za pomocą DHCP), wygląda na to, że działa. Jak w, ifconfigpokazuje poprawne IP i routepokazuje właściwe trasy. Jednak gdy przesyłam żądanie ARP przewodowego adresu IP, odpowiedź ARP zawiera bezprzewodowy adres MAC.

??? Na robocie nie ma mostu, więc dlaczego nie mam przewodowego MAC ???

Po odłączeniu drutu przewodowy adres IP odpowiada na polecenie ping ...

Dlaczego robot odpowiada przez interfejs bezprzewodowy na żądania IP na kablu?

EDYCJA: zarówno przewodowe, jak i bezprzewodowe karty sieciowe w tej samej podsieci IP. Wykonuję żądanie ARP z komputera (próbowanego na różnych komputerach) w tej samej podsieci IP.

odpowiednie dane wyjściowe 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)

odpowiedni wynik trasy:

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

Jest to bardzo popularny linux, więc nie mam narzędzi takich jak artptables, iptables, sysctl, brctl itp.

EDYCJA: schemat zgodnie z życzeniem

EDYCJA: Zrzucam ruch i patrzę na tabelę ARP. Żądanie ARP z 192.168.0.110 zwraca odpowiedź ARP zawierającą 24: 3C: 20: 06: 3E: 6D. Źródłowy adres MAC pakietu odpowiedzi ARP to również 24: 3C: 20: 06: 3E: 6D. Próbowałem majstrować przy _filter, _ignore i _announce, jak wspomniano tutaj , ale bezskutecznie.

EDYCJA: ustawienie bramy (na każdym interfejsie) nie robi różnicy (tak jak nie powinno).

EDYCJA: działało dobrze w poprzedniej wersji systemu operacyjnego (opartej na openembedded). czy to możliwe, że coś zmienili?

To, co widzisz, to normalne zachowanie, gdy masz dwa interfejsy w tej samej sieci. Jest to opisane w tym artykule LWN .

Kiedy mówisz, że otrzymujesz odpowiedź ARP dla niewłaściwego interfejsu, czy faktycznie odrzucasz ruch, czy po prostu patrzysz na wynikową tabelę ARP? Możliwe, że otrzymujesz odpowiedzi ARP na oba interfejsy ...

W każdym razie uważam, że odpowiedź na twój problem polega na odpowiednim manipulowaniu rp_filteri arp_filter. Dokumentacja każdego z nich znajduje się poniżej.

Proponuję najpierw spróbować:

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

Państwo może trzeba dokonać tej zmiany, a także:

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

rp_filter - BOOLEAN
    1 - wykonaj sprawdzanie źródła przez odwróconą ścieżkę, jak określono w RFC1812
        Zalecana opcja dla pojedynczych hostów i sieci pośredniczącej
        routery. Może powodować problemy w skomplikowanych (nie pętlowych)
        sieci z wolnym, niewiarygodnym protokołem (rodzaj RIP),
        lub używając tras statycznych.

    0 - Brak sprawdzania poprawności źródła.

    conf / all / rp_filter musi być również ustawiony na PRAWDA, aby dokonać weryfikacji źródła
    na interfejsie

    Wartość domyślna to 0. Zauważ, że niektóre dystrybucje ją umożliwiają
    w skryptach startowych.

arp_filter - BOOLEAN
    1 - Umożliwia jednoczesne korzystanie z wielu interfejsów sieciowych
    podsieć i poproś o odpowiedzi na ARP dla każdego interfejsu
    na podstawie tego, czy jądro kieruje pakiet, czy nie
    ARP'd IP poza tym interfejsem (dlatego musisz użyć źródła
    oparte na routingu, aby to działało). Innymi słowy, pozwala kontrolować
    z których karty (zwykle 1) odpowiedzą na żądanie arp.

    0 - (domyślnie) Jądro może odpowiadać na żądania arp z adresami
    z innych interfejsów. Może się to wydawać niewłaściwe, ale zwykle powoduje
    sens, ponieważ zwiększa szansę na udaną komunikację.
    Adresy IP są własnością całego hosta w systemie Linux, a nie
    szczególne interfejsy. Tylko w przypadku bardziej złożonych konfiguracji, takich jak ładowanie
    równoważenie, czy to zachowanie powoduje problemy.

    arp_filter dla interfejsu zostanie włączony, jeśli przynajmniej jeden z nich
    conf / {all, interface} / arp_filter jest ustawiony na PRAWDA,
    w przeciwnym razie zostanie wyłączone

Aby uzyskać dokładniejsze leczenie, zobacz ten artykuł:

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

Wiem, że to stary problem, ale ostatnio spotkałem dokładnie taką samą sytuację z urządzeniem osadzonym. Urządzenie ma interfejs Ethernet i Wi-Fi, a wymagania są takie, że oba interfejsy mogą być aktywne i w tej samej sieci w dowolnym momencie, ale ruch sieciowy musi być kierowany przez „preferowany” interfejs.

Większość użytkowników nie skonfigurowałaby tam urządzeń w ten sposób, ale teoretycznie powinno to być możliwe.

Najpierw wykryliśmy problemy z routerami Netgear, ponieważ zgłaszały one konflikt adresów IP - 2 adresy MAC współdzieliły jeden adres IP. Najwyraźniej router zacząłby źle działać w tym scenariuszu i zepsuć sieć użytkowników.

Utworzyłem prywatną sieć, która zawierała tylko router (Ethernet + Wi-Fi), Windows Laptop (tylko Ethernet) oraz urządzenie wbudowane (Ethernet + WiFi). Za pomocą wireshark, tcpdump na urządzeniu i arp w systemie Windows widzę następujące zachowanie:

1. Ifconfig na urządzeniu pokazuje różne adresy IP wln i Ethernet oraz różne adresy MAC
2. Czasami (bardzo rzadko) i arp –a z Windows pokazuje prawidłową kombinację IP-MAC.
3. Przez większość czasu arp –a z systemu Windows pokazuje, że zarówno wln, jak i eth0 mają ten sam adres MAC
4. Podczas pingowania wln lub eth0 z systemu Windows odpowiedź ping pochodzi z wln, a bardzo rzadko z eth0. tcpdump pokazuje, że wln odpowiedział tylko na 1 z 4 pingów (na przykład)
5. Gdy system Windows wysyła komunikat „kto ma” arp dla adresu IP eth0 - zarówno interfejsy eth0, jak i wln odpowiadają, że mają ten adres IP

Wierzę, że pozycja 3 jest spowodowana przez pozycję 5. Tablice arp są pomieszane, ponieważ wln odpowiada na komunikaty arp, na które powinien odpowiadać tylko eth0. Wydaje mi się, że pozycja 4 jest również spowodowana przez pozycję 5. Ping jest wysyłany na podstawie adresu MAC, a ponieważ ostatnia otrzymana wiadomość arp pochodziła od wln, mówiąc, że ma adres IP eth0, pingi są niepoprawnie kierowane do interfejsu wln.

Po wielu kopaniach i testach rozwiązanie było naprawdę bardzo proste. Zobacz ten artykuł - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Sterowniki sieciowe jądra systemu Linux są skonfigurowane w taki sposób, że gdy otrzymane zostanie żądanie arp dla znanego interfejsu (nawet jeśli zostanie odebrane w innym interfejsie), odpowie na arp.

To ustawienie rozwiązuje problem:

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

Wyjaśnienie:

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

Ponieważ działało to dobrze w poprzedniej wersji systemu operacyjnego (opartego na openembedded), moim rozwiązaniem było zaczekać na następną wersję systemu operacyjnego. Podejrzewam, że bezprzewodowy moduł jądra był wadliwy.

W odpowiedzi na komentarz Insyte.

Zróbmy nazewnictwo:

• PC1 - w prawym górnym rogu
• PC2 - lewy górny róg
• PC3 - lewy dolny róg

Ponieważ masz dostęp do robota z 3 komputerów za pośrednictwem mediów przewodowych i bezprzewodowych. Ponieważ są one w tej samej podsieci, nie można z całą pewnością stwierdzić, w jaki sposób zostało wysłane żądanie arp dla przewodowych mediów. Rozumiem przez to, że kiedy przełącznik rozgłasza żądanie ARP, twój robot odbiera go na obu interfejsach [nawiązując do twojego schematu], więc dla otrzymania żądania ARP dla adresu IP na nośniku przewodowym na nośniku bezprzewodowym zbyt duże są szanse odpowiedział na adres fizyczny nośnika bezprzewodowego, ponieważ skrzynka ma skonfigurowany adres IP

Miałem ten problem w przeszłości, nie był dokładny do twojego, ale był podobny. Domyślnie Linux odpowiada na adres fizyczny interfejsu, który otrzymuje żądanie arp, niezależnie od tego, na którym interfejsie skonfigurowano adres IP. Tak więc w twoim przypadku podłącz PC3 bezpośrednio do interfejsu eth0 robota i zrób zapytanie arp dla 192.168.0.101, to odpowie ci fizycznym adresem interfejsu eth0 zamiast ra0.

Mój scenariusz wdrożenia to:

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

Jest to ten sam przełącznik, z którym łączą się oba interfejsy. Mam nadzieję, że to ci pomoże.

W interfejsie routera skonfigurowano główny i dodatkowy adres IP dla dwóch różnych sieci na dwóch różnych interfejsach na serwerze. Ale otrzymując żądanie arp na eth1 dla adresu IP eth0, odpowiedział na fizyczny adres eth1

Aby temu zapobiec, do tej pory działało dla mnie

# 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

umieść go gdzieś na robocie, aby można go było zastosować podczas rozruchu.

Zalecenia: Zalecam skonfigurowanie dwóch różnych podsieci (powiedzmy 192.168.1.x / 24 na ra0 i 192.168.2.x / 24 na eth0), możesz użyć aliasów IP na swoich komputerach, a twój robot byłby dostępny na każdym z dwóch adresów IP. Nie można mieć dwóch ścieżek wychodzących dla tej samej podsieci na tym samym hoście. Nie, chyba że jest coś, co sprawia, że ​​twój robot woli od siebie. Twój robot może wybrać tylko jedną ścieżkę, aby wysłać z niego pakiety.

Niektóre odczyty: arp_announce , arp_ignore

myślę, że istnieje błędna konfiguracja między twoim bezprzewodowym punktem dostępowym a twoim przełącznikiem. switch i AP mylą się, gdzie wysłać pakiety. nie jestem tego pewien. myślę też, że powinieneś spróbować zdefiniować bramę, w której programy mogą wiedzieć, gdzie wysłać pakiety. coś jak

route add default gw 192.168.0.1