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, ifconfig
pokazuje poprawne IP i route
pokazuje 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?
Odpowiedzi:
To, co widzisz, to normalne zachowanie, gdy masz dwa interfejsy w tej samej sieci. Jest to opisane w tym artykule LWN .
źródło
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_filter
iarp_filter
. Dokumentacja każdego z nich znajduje się poniżej.Proponuję najpierw spróbować:
Państwo może trzeba dokonać tej zmiany, a także:
Aby uzyskać dokładniejsze leczenie, zobacz ten artykuł:
http://www.embedded-bits.co.uk/tag/rp_filter/
źródło
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:
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:
źródło
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.
źródło
W odpowiedzi na komentarz Insyte.
Zróbmy nazewnictwo:
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
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
źródło
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
źródło