Raspberry Pi ne peut pas envoyer de ping aux adresses de routeur ou Internet via un pont Wi-Fi

10

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.

Paul
la source
Si vous avez un client sans fil vers le routeur 2, pouvez-vous faire un ping vers / depuis la framboise vers le client sans fil?
MariusMatutiae
Oui. Vous pouvez envoyer une requête ping à la framboise à partir d'un client sans fil sur le routeur 1 ou le routeur 2.
Paul
Sur le routeur 1, avez-vous activé DHCP ou dnsmasq?
MariusMatutiae
DHCP oui, je ne connais pas dnsmasq. Il n'y a pas de paramètre pour cela dans l'interface web sur le routeur 1.
Paul
C'est pourquoi NAT craint. Vous devriez vraiment utiliser WDS à la place. (Chaque appareil semble avoir la même adresse MAC car NAT est utilisé pour convaincre le point d'accès qu'il parle à son client.)
David Schwartz

Réponses:

1

+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ème

Vous 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 arp

Vous 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.

ripat
la source
1

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.

Lam Do
la source
0

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:

 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, 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

  auto eth0
  iface eth0 inet dhcp

Ensuite, j'essayerais de redémarrer l'interface:

  ifdown eth0
  ifup eth0

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:

J'avais commandé un autre Raspberry Pi et je viens de réimager la carte SD, démarré dans celui-ci, et Internet a bien fonctionné. J'ai sorti la carte SD et l'ai mise dans le vieux Raspberry Pi et j'ai branché les mêmes câbles et le câble Ethernet, mais cela n'a toujours pas fonctionné ....

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.

MariusMatutiae
la source
Il n'y a aucune différence entre la réponse aux deux commandes ping. Identique à ce que j'ai collé ci-dessus. Le fichier / etc / network / interfaces est vide dans le cas raspbmc, dans le cas raspbian a "auto lo" "iface lo inet loopback" "iface eth0 inet dhcp". Le redémarrage de l'interface ne fait rien dans les deux cas. Ce n'est certainement pas un problème avec le Raspberry Pi, car j'ai deux pis de framboise différents, aucun ne fonctionne lorsqu'il est branché sur le routeur 2, mais les deux fonctionnent lorsqu'ils sont connectés directement au routeur 1.
Paul
-1

Problème similaire que j'ai eu il y a quelque temps. Ma solution consistait à modifier le /etc/resolv.conffichier en ajoutant nameserver 8.8.4.4et en redémarrant les interfaces à l'aide de /etc/init.d/networking restart. Ça marche pour moi.

Mubin
la source
OP mentionne une Destination Host Unreachableerreur, ce qui semble suggérer que le DNS fonctionne correctement. Une erreur DNS aurait produit quelque chose comme cannot resolveou Unknown host.
jornane