Ich habe vor kurzem einen WNR2000v3-Router mit DD-WRT als eine Art Repeater-Bridge eingerichtet, mit der "Atheros"-Version vondieses Tutorial(wir nennen das „Router 2“), der einen Medialink Wireless-N-Router wiederholt (wir nennen das „Router 1“). Das funktioniert perfekt für mein Android-Telefon und meinen Windows-Computer sowohl über WLAN als auch bei direkter Verbindung über Ethernet, aber wenn ich meinen Raspberry Pi anschließe, entweder wenn ich Raspbian (wheezy) oder Raspbmc ausführe, kann ich keine Verbindung außerhalb des lokalen Netzwerks herstellen.
Der Raspberry Pi kann alle anderen Geräte im lokalen Subnetz anpingen (und von ihnen angepingt werden), einschließlich „Router 2“, mit dem er direkt verbunden ist, und er kann DHCP von Router 1 abrufen. Wenn ich jedoch versuche, Router 1 anzupingen, erhalte ich die Meldung „Zielhost nicht erreichbar“. Und wenn ich versuche, irgendetwas im Internet anzupingen, z. B. google.com oder superuser.com, erhalte ich ebenfalls die Meldung „Zielhost nicht erreichbar“.
Hier ist ein anderer Computer im Netzwerk:
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
Hier ist 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 ist die Adresse des 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)
Hier ist die Routing-Tabelle:
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
Und hier ist die DHCP-Anfrage:
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.
Alles andere funktioniert einwandfrei, aber ich habe diesen Raspberry Pi mit zwei verschiedenen Images (Raspbmc und Raspbian) und zwei verschiedenen Raspberry Pis ausprobiert und keine Konfiguration funktioniert. Das Raspbian-Image wurde getestet und funktioniert, wenn es direkt an Router 1 angeschlossen ist. Dieses Problem scheint sehr ähnlich zu sein wiediese unbeantwortete Fragevon vor zwei Jahren, außer dass er in diesem Fall anscheinend WLAN für das Gerät verwendet hat, das keine Verbindung herstellen konnte, und tatsächlich zeitweise eine Verbindung hergestellt wurde. Außerdem kam die Ping-Antwort dort vom Router, nicht vom Gerät. Was könnte dieses Problem verursachen?
Bearbeiten:Ich sollte auch erwähnen, dass die beiden verschiedenen Raspberry Pis unterschiedliche IP-Adressen hatten, von denen eine IP-MAC-gebunden war, und dass es in der DHCP-Tabelle keine IP-Kollisionen gab, sondern auf beiden das gleiche Problem bestand.
Aktualisieren: Ich habe eine möglicherweise interessante Sache festgestellt, nämlich dass die Repeater-Bridge nicht mehr funktioniert, wenn das Klonen von MAC-Adressen ausgeschaltet ist – das einzige, was den Raspberry Pi anpingen kann, ist Router 2, und es gibt keine Verbindung (oder Zugriff auf Router 1) von irgendetwas, das nur mit Router 2 verbunden ist – einschließlich der Windows-Maschine. Die geklonte MAC-Adresse ist jedoch dieselbe MAC-Adresse, die ohnehin von den Schnittstellen von Router 2 verwendet wird (laut der „Status“-Seite). Ich habe sowohl Router 1 als auch Router 2 zweimal aus- und wieder eingeschaltet und es macht keinen Unterschied. Ich verstehe nicht, warum das Klonen von MAC-Adressen hier relevant ist. Wenn das Klonen von MAC-Adressen ausgeschaltet ist und ich mich per SSH mit dem Router selbst verbinde, kann der Router den Raspberry Pi anpingen, aber nicht Router 1.
Eine weitere Kleinigkeit ist, dass, wenn das Klonen von MAC-Adressen aktiviert ist und ich tatsächlich andere Computer im Netzwerk anpingen kann, ARPing für jedes Gerät, das auf Pings antwortet, dieselbe MAC-Adresse zurückgibt.
Aktualisierung 2:Beim Überprüfen der Syslog-Werte stellte ich fest, dass diese Fehlermeldung bezüglich der MAC-Adresse vorhanden war:
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
Offenbar handelt es sich hier um einebekanntes Problemdie Leute durch Klonen von MAC-Adressen lösen. Ich bin mir nicht ganz sicher, warum die zufälligen MAC-Adressen ein Problem darstellen und welche weiteren Folgen das Klonen von MAC-Adressen hat.
Antwort1
+1 für die ausführliche Problembeschreibung.
Wie ich bereits in dem von Ihnen eröffneten Thread vorgeschlagen habe,Himbeer-Pi, können Sie überprüfen, ob Ihr Hauptrouter in der ARP-Tabelle des RPi aufgeführt ist: arp -noder ob Sie IProute2 installiert haben: ip neigh.
Bei Bedarf können Sie den Router mit diesem Befehl zum ARP-Cache hinzufügen: arp -s <ROUTER_IP> <ROUTER_MAC>und prüfen, ob das Problem weiterhin besteht
Sie können auch prüfen, ob Ihr RPi die ARP-Anfrage wie erwartet sendet, indem Sie alle ARP-Pakete abhören. Führen Sie auf Ihrem RPi Folgendes aus:tcpdump arp
Sie können denselben Befehl auch auf dem DD-WRT-Repeater und auf jedem anderen Host ausführen, der mit Router 1 verbunden ist. Da die ARP-Anfragen gesendet werden, sollten Sie sie in Ihrem gesamten LAN sehen können.
Antwort2
Ich hatte das gleiche Problem bei der Installation eines neuen WLAN-Repeaters. Die Kompromisslösung besteht darin, die statische IP für Raspberry Pi festzulegen.
Antwort3
Dies ist schwierig zu diagnostizieren, da Ihr System natürlich korrekt konfiguriert zu sein scheint. Anstatt eine lange Liste von Prüfoptionen durchzugehen, werde ich Ihnen einige Ideen für Dinge geben, die Sie testen können.
Ich würde beispielsweise versuchen, das Standard-Gateway auf Router 2 statt auf Router 1 zu ändern.
Eine andere Möglichkeit besteht darin, Ping zu zwingen, sich an die Schnittstelle eth0 zu binden:
ping -I 192.168.0.107 192.168.0.1
ping -I eth0 192.168.0.1
Diese beiden Befehle unterscheiden sich geringfügig. Sie sollten beide ausprobieren. Hoffentlich liefern sie unterschiedliche Ergebnisse, was auf einen Fehler hinweisen würde.
Dann würde ich /etc/network/interfaces überprüfen: Enthält es ein paar Zeilen wie
auto eth0
iface eth0 inet dhcp
Dann würde ich versuchen, die Schnittstelle neu zu starten:
ifdown eth0
ifup eth0
und dann erneut dhclient.
Letzten Endes sollte man bedenken, dass es sich nicht unbedingt um ein Softwareproblem handeln muss. Wenn Sie zudiese Webseitekönnen Sie folgenden Erfahrungsbericht lesen:
Ich hatte einen anderen Raspberry Pi bestellt und einfach die SD-Karte neu gespiegelt, damit hochgefahren und das Internet funktionierte einwandfrei. Ich nahm die SD-Karte heraus und steckte sie in den alten Raspberry Pi und schloss genau dieselben Kabel und das gleiche Ethernet-Kabel an, aber es funktionierte immer noch nicht ...
Sie sollten auch bedenken, dass möglicherweise ein Problem mit dem Kabel vorliegt. Kabel funktionieren nicht/funktionieren nicht. Ein Problem beim Empfang oder Senden kann dazu führen, dass viele Frames verloren gehen, die Signalqualität grenzwertig ist usw. In diesem Fall verhalten sich Protokolle wie TCP besser als ICMP oder UDP, da sie Pakete, die nicht vom Ziel empfangen wurden, erneut übertragen, was Ihnen den falschen Eindruck einer ordnungsgemäß funktionierenden Verbindung vermittelt. Dieser falsche Eindruck bleibt natürlich bestehen, bis Sie die Verbindungsgeschwindigkeit messen.
Antwort4
Ein ähnliches Problem hatte ich vor einiger Zeit. Meine Lösung bestand darin,
/etc/resolv.confdie Datei durch Hinzufügen von zu bearbeiten nameserver 8.8.4.4und die Schnittstellen mit neu zu starten /etc/init.d/networking restart. Bei mir funktioniert es.