Raspberry Pi ne peut pas envoyer de ping au routeur ou aux adresses Internet via un pont wifi
J'ai récemment configuré un routeur WNR2000v3 exécutant DD-WRT comme une sorte de pont de répéteur utilisant la version "Atheros" de ce tutoriel (nous appellerons ce "routeur 2"), qui répète un Medialink. Routeur sans fil N (nous appellerons ce "routeur 1"). Cela fonctionne parfaitement pour mon téléphone Android et mon ordinateur Windows à la fois via le réseau wifi et directement connecté via Ethernet, mais lorsque je connecte mon Raspberry Pi, que ce soit sous Raspbian (Wheezy) ou Raspbmc, je ne parviens pas à obtenir une connexion en dehors du réseau local.
Le Raspberry Pi peut envoyer un ping (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 peut obtenir le protocole DHCP du routeur 1, mais j’essaie de Je reçois le message "Hôte de destination inaccessible" sur le routeur 1, et si j'essaie de cingler sur Internet comme google.com, superuser.com, le message "Hôte de destination inaccessible" est similaire.
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 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 restée sans réponse il ya deux ans, sauf que dans ce cas, il semble qu’il utilisait le wifi pour la appareil qui n'a pas réussi à se connecter, et il obtenait en fait une connectivité intermittente. De plus, la réponse du ping émanait du routeur, pas du périphérique. Qu'est-ce qui pourrait causer ce problème?
Modifier: Je dois également noter que les deux pis différents de framboise avaient des adresses IP différentes, dont l'une était liée à l'adresse IP-MAC et que je n'ai vu aucune collision IP dans le protocole DHCP. table, mais le même problème sur chacun.
Update : j'ai déterminé une chose potentiellement intéressante, à savoir que lorsque le clonage d'adresse MAC est désactivé, le pont de répéteur cesse de fonctionner - la seule chose qui puisse envoyer un ping au Raspberry Pi est routeur 2, et il n'y a pas de connectivité (ou d'accès au routeur 1) à partir de tout ce qui est connecté uniquement au routeur 2 - y compris la machine Windows. Cependant, l'adresse mac en cours de clonage est la même adresse que celle utilisée actuellement par les interfaces du routeur 2 (conformément à la page "status"). J'ai mis sous tension le routeur 1 et le routeur 2 deux fois et cela ne fait aucune différence. Je ne comprends pas pourquoi le clonage d'adresses MAC est pertinent ici. Lorsque le clonage d'adresse MAC est désactivé, lorsque je ssh dans le routeur lui-même, celui-ci peut envoyer une requête ping à 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 envoyer un ping à d'autres ordinateurs du réseau, arping renvoie la même adresse MAC pour chaque périphérique répondant aux pings.
Mise à jour 2: Après vérification des valeurs de syslog, j'ai constaté qu'il y avait un message d'erreur concernant 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, il s’agit d’un problème conn que les gens résolvent en utilisant le clonage d’adresses MAC. Je ne sais pas exactement pourquoi les adresses MAC aléatoires posent problème, ni quelles sont les autres conséquences du clonage des adresses MAC.
+1 pour la description détaillée du problème.
Comme je l'ai suggéré sur le fil que vous avez ouvert dans Raspberry Pi , vous pouvez vérifier si votre routeur principal figure dans la table arp du RPi: arp -n ou si vous avez l'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 voir si le problème persiste.
Vous pouvez également vérifier si votre RPi envoie la demande ARP comme prévu en détectant tous les paquets ARP. Sur votre RPi, lancez: tcpdump arp
Vous pouvez également exécuter la même commande sur le répéteur DD-WRT et sur tout autre hôte connecté au routeur 1. Lors de la diffusion des demandes ARP, vous devriez les voir sur votre réseau local.
J'ai eu le même problème lors de l'installation du nouveau répéteur Wifi. La solution compromise est l’adresse IP statique de Raspberry Pi.
Ceci est difficile à diagnostiquer car votre système semble bien configuré. Ainsi, plutôt que de passer en revue une longue liste d'options de vérification, je vais vous donner quelques idées de tests.
Une chose que je voudrais essayer est de changer la passerelle par défaut pour le routeur 2, plutôt que le routeur 1.
Une autre chose à faire est de forcer ping à se connecter à l'interface eth0:
ping -I 192.168.0.107 192.168.0.1
ping -I eth0 192.168.0.1
Ces deux commandes sont légèrement différentes, il faut essayer les deux. Espérons qu'ils donneront des sorties différentes, ce qui indiquerait une faute.
Ensuite, je vérifierais/etc/network/interfaces: cela contient-il quelques lignes comme
auto eth0
iface eth0 inet dhcp
Ensuite, je voudrais essayer de redémarrer l'interface:
ifdown eth0
ifup eth0
et puis dhclient à nouveau.
En fin de compte, il ne faut pas oublier qu'il ne s'agit pas d'un problème de logiciel. Si vous allez sur cette page Web , vous pouvez lire l'expérience suivante:
J'avais commandé un autre Raspberry Pi et réimaginais la carte SD, démarré dans celle-ci, et Internet fonctionnait bien. J'ai sorti la carte SD et l'ai mise dans l'ancien Raspberry Pi et ai branché les mêmes câbles et le même câble Ethernet, mais cela ne fonctionnait toujours pas ....
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 l’abandon de nombreuses images, la qualité marginale du signal, etc. Dans ce cas, des protocoles tels que 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 une impression erronée d'une connexion fonctionnant correctement. Cette mauvaise impression perdure bien entendu jusqu'à ce que vous mesuriez la vitesse de connexion.