Raspberry pi nie może pingować routera ani adresów internetowych przez mostek Wi-Fi

Niedawno skonfigurowałem router WNR2000v3 z systemem DD-WRT jako swego rodzaju mostek repeatera, używając wersji tego samouczka „Atheros” (nazywamy to „routerem 2”), który powtarza router Medialink Wireless-N (my ” Nazywam to „routerem 1”). Działa to doskonale na moim telefonie z Androidem i komputerze z systemem Windows zarówno przez Wi-Fi, jak i po bezpośrednim połączeniu przez Ethernet, ale gdy podłączę Raspberry pi, albo podczas uruchamiania Raspbian (wheezy) lub Raspbmc, nie mogę uzyskać żadnego połączenia poza siecią lokalną.

Raspberry pi może pingować (i być pingowanym przez) dowolnym innym urządzeniem w lokalnej podsieci, w tym „routerem 2”, do którego jest bezpośrednio podłączony, i może uzyskać DHCP z routera 1, ale kiedy spróbuję i ping router 1, dostaję „Destination Host Unreachable”, a jeśli spróbuję pingować cokolwiek w Internecie, np. google.com, superuser.com, podobnie otrzymuję „Destination Host Unreachable”.

Oto inny komputer w sieci:

ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=1 ttl=127 time=38.7 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=127 time=1.67 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=127 time=1.73 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=127 time=3.56 ms
--- 192.168.0.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.672/11.418/38.705/15.772 ms

Oto router 1:

ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.107 icmp_seq=1 Destination Host Unreachable
From 192.168.0.107 icmp_seq=2 Destination Host Unreachable
From 192.168.0.107 icmp_seq=3 Destination Host Unreachable
From 192.168.0.107 icmp_seq=4 Destination Host Unreachable
From 192.168.0.107 icmp_seq=5 Destination Host Unreachable
From 192.168.0.107 icmp_seq=6 Destination Host Unreachable
--- 192.168.0.1 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7007ms
pipe 3

192.168.0.107 to adres Raspberry Pi:

ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:db:c9
          inet addr:192.168.0.107  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3753 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1262 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:595127 (581.1 KiB)  TX bytes:112407 (109.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:285 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:27703 (27.0 KiB)  TX bytes:27703 (27.0 KiB)

Oto tabela routingu:

sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

A oto żądanie DHCP:

sudo dhclient -v eth0
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/xx:xx:xx:xx:db:c9
Sending on   LPF/eth0/xx:xx:xx:xx:db:c9
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
RTNETLINK answers: File exists
bound to 192.168.0.107 -- renewal in 274691 seconds.

Wszystko inne działa dobrze, ale próbowałem tego rapsberry pi z dwoma różnymi obrazami (Raspbmc i raspbian) i dwoma różnymi malinowymi pisami i bez konfiguracji. Obraz raspbian został przetestowany jako działający, gdy jest bezpośrednio podłączony do routera 1. Ten problem wydaje się bardzo podobny do tego pytania bez odpowiedzi sprzed dwóch lat, z tym wyjątkiem, że w takim przypadku wydaje się, że używał Wi-Fi dla urządzenia, które nie mogło się połączyć, i w rzeczywistości dostawał sporadyczne połączenia. Również odpowiedź ping była z routera, a nie z urządzenia. Co może być przyczyną tego problemu?

Edycja: Powinienem również zauważyć, że dwa różne maliny pis miały różne adresy IP, z których jeden był powiązany z IP-MAC, i nie było żadnych kolizji IP, które widziałem w tabeli DHCP, ale ten sam problem na każdym.

Aktualizacja : Ustaliłem jedną potencjalnie interesującą rzecz, a mianowicie to, że po wyłączeniu klonowania adresu MAC mostek repeatera przestaje działać - jedyną rzeczą, która może pingować Raspberry Pi, jest router 2 i nie ma łączności (ani dostępu do routera) 1) z dowolnego urządzenia podłączonego tylko do routera 2 - w tym komputera z systemem Windows. Jednak klonowany adres mac jest tym samym adresem mac, który jest faktycznie używany przez interfejsy routera 2 (zgodnie ze stroną „status”). Dwukrotnie przełączyłem zasilanie routera 1 i routera 2 i to nie ma znaczenia. Nie rozumiem, dlaczego klonowanie adresów MAC jest tutaj istotne. Gdy klonowanie adresu MAC jest wyłączone, kiedy ssh do samego routera, router może pingować Raspberry pi, ale nie router 1.

Inną małą rzeczą jest to, że gdy klonowanie adresu MAC jest włączone i mogę pingować inne komputery w sieci, arping zwraca ten sam adres mac dla każdego urządzenia, które odpowiada na ping.

Aktualizacja 2: po sprawdzeniu wartości syslog stwierdziłem, że pojawił się ten komunikat o błędzie dotyczący adresu MAC:

Jan  1 00:00:08 Router 2 kern.err kernel: [    6.770000] ath: eeprom contains invalid mac address: ff:ff:ff:ff:ff:ff
Jan  1 00:00:08 Router 2 kern.err kernel: [    6.780000] ath: random mac address will be used: fa:55:da:33:19:a9

Najwyraźniej jest to znany problem, który ludzie rozwiązują za pomocą klonowania adresów MAC. Nie jestem do końca pewien, dlaczego losowe adresy MAC stanowią problem i jakie inne konsekwencje ma klonowanie adresów MAC.

+1 za szczegółowy opis problemu.

Jak sugerowano na gwincie otwartego w Raspberry Pi , można sprawdzić, czy główny router jest wymieniony w tabeli ARP RPI jest: arp -nczy masz zainstalowany iproute2: ip neigh.

W razie potrzeby możesz dodać router do pamięci podręcznej arp za pomocą tego polecenia: arp -s <ROUTER_IP> <ROUTER_MAC>i sprawdź, czy nadal masz problem

Możesz również sprawdzić, czy Twoje RPi wysyła żądanie ARP zgodnie z oczekiwaniami, wąchając wszystkie pakiety ARP. Na swoim RPi uruchom:tcpdump arp

Możesz również uruchomić to samo polecenie na repeaterze DD-WRT i na dowolnym innym hoście podłączonym do routera 1. Gdy żądania ARP są rozgłaszane, powinieneś je zobaczyć w sieci LAN.

Miałem ten sam problem podczas instalowania nowego wzmacniacza Wi-Fi. Kompromisowym rozwiązaniem jest ustawienie statycznego adresu IP dla Raspberry Pi.

Jest to trudne do zdiagnozowania, ponieważ oczywiście system wydaje się poprawnie skonfigurowany. Zamiast więc przeglądać długą listę opcji sprawdzania, dam ci kilka pomysłów na rzeczy do przetestowania.

Chciałbym zmienić domyślną bramę do routera 2, a nie router 1.

Kolejną rzeczą jest wymuszenie na pingu powiązania z interfejsem eth0:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

Te dwie komendy są nieco inne, obie powinny zostać wypróbowane. Miejmy nadzieję, że dadzą różne wyjścia, co byłoby oznaką usterki.

Następnie sprawdziłbym / etc / network / interfaces: czy zawiera on kilka linii takich jak

  auto eth0
  iface eth0 inet dhcp

Następnie spróbuję ponownie uruchomić interfejs:

  ifdown eth0
  ifup eth0

a potem znowu dhclient.

Kiedy wszystko jest powiedziane i zrobione, należy pamiętać, że nie musi to stanowić problemu z oprogramowaniem. Jeśli przejdziesz na tę stronę internetową , możesz przeczytać następujące wrażenia:

Zamówiłem kolejną malinową pi i po prostu ponownie sfotografowałem kartę SD, uruchomiłem ją, a internet działał dobrze. Wyjąłem kartę SD i włożyłem ją do starego malinowego pi i podłączyłem dokładnie te same kable i kabel Ethernet, ale nadal nie działało ...

Należy również pamiętać, że istnieje możliwość wystąpienia problemu z kablem. Kable nie działają / nie działają na obiektach. Problem w RX lub TX może powodować upuszczenie wielu ramek, jakość sygnału marginalną i tak dalej. W takim przypadku protokoły takie jak TCP zachowują się lepiej niż ICMP lub UDP, ponieważ ponownie przesyłają pakiety, które nie zostały odebrane przez cel, co daje błędne wrażenie poprawnie działającego połączenia. To błędne wrażenie trwa, dopóki nie zmierzysz prędkości połączenia.

Podobny problem miałem jakiś czas temu. Moim rozwiązaniem było edytowanie /etc/resolv.confpliku poprzez dodanie nameserver 8.8.4.4i ponowne uruchomienie interfejsów za pomocą /etc/init.d/networking restart. Mi to pasuje.