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.