J'ai récemment mis en place un routeur WNR2000v3 exécutant DD-WRT comme une sorte de pont répéteur en utilisant la version "Atheros" de ce tutoriel (nous l'appellerons "routeur 2"), qui répète un routeur Medialink Wireless-N (nous " Je l'appellerai 'routeur 1'). Cela fonctionne parfaitement pour mon téléphone Android et mon ordinateur Windows à la fois via le wifi et directement connecté via Ethernet, mais lorsque je branche mon Raspberry pi, que ce soit lors de l'exécution de Raspbian (wheezy) ou Raspbmc, je ne peux pas obtenir de connexion en dehors du réseau local.
Le Raspberry Pi peut cingler (et être cinglé par) n'importe quel autre périphérique du sous-réseau local, y compris le `` routeur 2 '', auquel il est directement connecté, et il est capable d'obtenir DHCP du routeur 1, mais quand j'essaie et ping routeur 1, j'obtiens "Destination Host Unreachable", et si j'essaie de cingler quoi que ce soit sur Internet comme google.com, superuser.com, j'obtiens également "Destination Host Unreachable".
Voici un autre ordinateur sur le réseau:
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
Voici le routeur 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 est l'adresse du 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)
Voici la table de routage:
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
Et voici la requête 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.
Tout le reste fonctionne bien, mais j'ai essayé ce rapsberry pi avec deux images différentes (Raspbmc et raspbian) et deux pis de framboise différents et aucune configuration ne fonctionne. L'image raspbian a été testée comme fonctionnant lorsqu'elle est directement connectée au routeur 1. Ce problème semble très similaire à cette question sans réponse d'il y a deux ans, sauf que dans ce cas, il semble qu'il utilisait le wifi pour l'appareil qui n'a pas réussi à se connecter, et il obtenait en fait une connectivité intermittente. La réponse ping a également été émise par le routeur, pas par l'appareil. Quelle pourrait être la cause de ce problème?
Edit: je devrais également noter que les deux différents framboises pis avaient des adresses IP différentes, dont l'une était liée à IP-MAC, et il n'y avait aucune collision IP que j'ai vu dans la table DHCP, mais le même problème sur chacun.
Mise à jour : j'ai déterminé une chose potentiellement intéressante, c'est que lorsque le clonage d'adresse MAC est désactivé, le pont de répéteur cesse de fonctionner - la seule chose qui peut cingler le raspberry pi est le routeur 2, et il n'y a pas de connectivité (ou d'accès au routeur 1) à partir de tout élément connecté uniquement au routeur 2 - y compris la machine Windows. Cependant, l'adresse mac qui est en cours de clonage est la même adresse mac qui est en fait utilisée par les interfaces du routeur 2 de toute façon (selon la page "état"). J'ai redémarré deux fois le routeur 1 et le routeur 2 et cela ne fait aucune différence. Je ne comprends pas pourquoi le clonage d'adresse MAC est pertinent ici. Avec le clonage d'adresse MAC désactivé, lorsque je ssh dans le routeur lui-même, le routeur peut envoyer une requête ping au Raspberry pi, mais pas au routeur 1.
Une autre petite chose est que lorsque le clonage d'adresse MAC est activé et que je peux réellement cingler d'autres ordinateurs sur le réseau, arping renvoie la même adresse mac pour chaque appareil qui répond aux pings.
Mise à jour 2: En vérifiant les valeurs syslog, j'ai constaté qu'il y avait ce message d'erreur relatif à l'adresse 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
Apparemment, c'est un problème connu que les gens résolvent en utilisant le clonage d'adresse MAC. Je ne sais pas exactement pourquoi les adresses MAC aléatoires sont un problème et quelles autres conséquences le clonage d'adresses MAC a.
Réponses:
+1 pour la description détaillée du problème.
Comme je l' ai suggéré sur le fil que vous avez ouvert dans pi framboise , vous pouvez vérifier si votre routeur principal est répertorié dans la table arp de RPI:
arp -nou si vous avez le iproute2 installé:ip neigh.Si nécessaire, vous pouvez ajouter le routeur dans le cache arp avec cette commande:
arp -s <ROUTER_IP> <ROUTER_MAC>et voyez si vous avez toujours le problèmeVous pouvez également vérifier si votre RPi envoie la demande ARP comme prévu en reniflant tous les paquets ARP. Sur votre RPi, exécutez:
tcpdump arpVous pouvez également exécuter la même commande sur le répéteur DD-WRT et sur tout autre hôte connecté sur le routeur 1. Lorsque les requêtes ARP sont diffusées, vous devez les voir sur votre réseau local.
la source
J'ai eu le même problème lors de l'installation du nouveau répéteur Wifi. La solution compromise est définie l'IP statique pour Raspberry Pi.
la source
C'est difficile à diagnostiquer, car bien sûr, votre système semble correctement configuré. Donc, plutôt que de parcourir une longue liste d'options de vérification, je vais vous donner quelques idées de choses à tester.
Une chose que j'essaierais est de changer la passerelle par défaut vers le routeur 2, plutôt que le routeur 1.
Une autre chose est de forcer ping à se lier à l'interface eth0:
Ces deux commandes sont légèrement différentes, les deux doivent être essayées. Avec un peu de chance, ils donneront différentes sorties, ce qui serait une indication d'un défaut.
Ensuite, je vérifierais / etc / network / interfaces: contient-il quelques lignes comme
Ensuite, j'essayerais de redémarrer l'interface:
puis dhclient à nouveau.
En fin de compte, il ne faut pas oublier que ce n'est pas nécessairement un problème logiciel. Si vous accédez à cette page Web, vous pouvez lire l'expérience suivante:
En outre, vous devez garder à l'esprit qu'il existe un risque de problème avec le câble. Les câbles ne fonctionnent pas / ne fonctionnent pas. Un problème dans RX ou TX peut entraîner la suppression de nombreuses trames, la qualité du signal peut être marginale, etc. Dans ce cas, les protocoles comme TCP se comportent mieux que ICMP ou UDP car ils retransmettent des paquets qui n'ont pas été reçus par la cible, ce qui vous donne la mauvaise impression d'une connexion fonctionnant correctement. Cette mauvaise impression dure bien sûr jusqu'à ce que vous mesuriez la vitesse de connexion.
la source
Problème similaire que j'ai eu il y a quelque temps. Ma solution consistait à modifier le
/etc/resolv.conffichier en ajoutantnameserver 8.8.4.4et en redémarrant les interfaces à l'aide de/etc/init.d/networking restart. Ça marche pour moi.la source
Destination Host Unreachableerreur, ce qui semble suggérer que le DNS fonctionne correctement. Une erreur DNS aurait produit quelque chose commecannot resolveouUnknown host.