Odpowiedzi ARP zawierają nieprawidłowy adres MAC

14

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

internetowy diagram

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?

Jayen
źródło
5
może diagram byłby fajny i mógłbyś w nim umieścić robota ... dodatkowe fajne punkty
The Unix Janitor
Czy karty przewodowe i bezprzewodowe są w tej samej podsieci IP? Skąd „wykonujesz żądanie ARP”? Pomocne może być uwzględnienie wyników „ifconfig” i wyświetlenie tabeli routingu.
Dave
Czy to kiedykolwiek zostało rozwiązane? Widzę podobny problem i całkowicie nie udało mi się znaleźć rozwiązania.
Kirk
1
wierzę, że moduł jądra karty bezprzewodowej został uszkodzony.
Jayen
1
Pytanie brzmi: DLACZEGO to robisz ... Zgaduję, że tego chcesz, aby gdy robot był mobilny, mógł mówić, ale po podłączeniu kabla Ethernet można uzyskać wysokie prędkości transferu? Jeśli tak, czy zastanawiałeś się nad połączeniem interfejsów przewodowych i bezprzewodowych, umieszczeniem ich w tym samym adresie IP, a następnie skonfigurowaniem go w taki sposób, aby jeśli przewodowy był włączony, miałby priorytet, ale jeśli nie, ruch przesyła się przez sieć bezprzewodową? Kiedyś konfigurowałem laptopa w ten sposób i działało świetnie, ale teraz mam 300 Mb / s zamiast 2 Mb / s, więc już tego nie robię.
Sean Reifschneider,

Odpowiedzi:

12

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

Sciurus
źródło
ustawienie arp_filter nie ma wpływu. Dlaczego nie?
Jayen
1
Ponieważ oba interfejsy mają trasy do sieci lokalnej, linux wyśle ​​pakiety z jednego z adresów IP z jednego z interfejsów. W ten sposób będzie odpowiadać na żądania ARP dla dowolnego adresu IP z obu interfejsów. Aby to zmienić, musisz nie tylko ustawić arp_filter na 1, ale także włączyć routing oparty na źródłach i skonfigurować tabele routingu, które zapewnią, że ruch dla każdego adresu IP wychodzi poza żądany interfejs. Jest to nieco inny scenariusz niż masz, ale wlug.org.nz/SourceBasedRouting może ci pomóc.
sciurus
4

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/

Insyte
źródło
1
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 to także 24: 3C: 20: 06: 3E: 6D. Wypróbowałem oba sugerowane ustawienia filtrów, ale bezskutecznie. Próbowałem także grać w _ignore i _announce, jak wspomniano tutaj .
Jayen,
4

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
dev-rowbot
źródło
Bardzo pouczająca odpowiedź, ale jak powiedział OP, spróbował tego i powiązał z podobną odpowiedzią serverfault.com/a/30648/57200
Jayen
1

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.

Jayen
źródło
Jest mało prawdopodobne, ponieważ oczekiwane zachowanie jest oczekiwane, jak wspomniano w @sciurus. Być może poprzednie wydanie, w którym „działało dobrze”, było błędne i naprawiono je :-). W rzeczywistości to, co reaguje jako ostatnie, to takie, które utknęło w tabeli ARP na drugim końcu. Ponieważ połączenie bezprzewodowe jest prawdopodobnie wolniejsze niż przewodowe, dostaniesz połączenie bezprzewodowe.
Sean Reifschneider,
0

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

Gaumire
źródło
arp_announce i arp_ignore nie działały dla mnie. zobacz mój komentarz na temat rozwiązania insyte. Dwie różne podsieci niestety nie są opcją. Ponadto, zgodnie z ostatnią edycją mojego pytania, działało dobrze w poprzedniej wersji systemu operacyjnego, więc mogę mieć dwie ścieżki wychodzące dla tej samej podsieci na tym samym hoście.
Jayen
-2

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

fmysky
źródło
laptopy zarówno przewodowe, jak i bezprzewodowe działają dobrze, więc nie jest to punkt dostępu ani przełącznik. brama jest niezbędna tylko wtedy, gdy próbuję wyjść poza podsieć. (i tak spróbowałem i nic to nie zmienia. Nie ma znaczenia, czy dodam bramę do eth0 lub ra0.)
Jayen
w twoim eth0 nie ma RX / TX, wskazuje na pewną konfigurację. błąd?
fmysky
hrm, myślę, że to prawda. eth0 powinien przynajmniej otrzymać żądanie ARP, ponieważ jest to transmisja, prawda?
Jayen
tak, tak myślałem
fmysky
problem arp w tym artykule wydaje się dotyczyć tylko jąder 2.4.x
fmysky