Raspberry pi no puede hacer ping en el enrutador o las direcciones de Internet a través del puente wifi


10

Recientemente configuré un enrutador WNR2000v3 que ejecuta DD-WRT como una especie de puente repetidor utilizando la versión "Atheros" de este tutorial (llamaremos a esto 'enrutador 2'), que está repitiendo un enrutador Medialink Wireless-N (nosotros ' llamaré a esto 'enrutador 1'). Esto funciona perfectamente para mi teléfono Android y computadora con Windows tanto a través de wifi como cuando se conecta directamente a través de ethernet, pero cuando conecto mi Raspberry pi, ya sea cuando ejecuto Raspbian (wheezy) o Raspbmc, no puedo obtener ninguna conexión fuera de la red local.

El raspberry pi puede hacer ping (y ser pinchado por) cualquiera de los otros dispositivos en la subred local, incluido el 'enrutador 2', al que está conectado directamente, y puede obtener DHCP desde el enrutador 1, pero cuando lo intento y hago ping al enrutador 1, obtengo "Host de destino inalcanzable", y si intento hacer ping a cualquier cosa en Internet como google.com, superuser.com, obtengo de manera similar "Host de destino inalcanzable".

Aquí hay otra computadora en la red:

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

Aquí está el enrutador 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 es la dirección de 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)

Aquí está la tabla de enrutamiento:

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

Y aquí está la solicitud de 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.

Todo lo demás funciona bien, pero he probado este rapsberry pi con dos imágenes diferentes (Raspbmc y raspbian) y dos raspberry pis diferentes y no funciona la configuración. Se ha probado que la imagen raspbian funcionaba cuando se conectaba directamente al enrutador 1. Este problema parece muy similar a esta pregunta sin respuesta de hace dos años, excepto que en ese caso parece que estaba usando wifi para el dispositivo que no se pudo conectar, y en realidad estaba obteniendo conectividad intermitente. Además, la respuesta de ping fue del enrutador, no del dispositivo. ¿Qué podría estar causando este problema?

Editar: También debo tener en cuenta que los dos diferentes tipos de frambuesa tenían direcciones IP diferentes, una de las cuales estaba vinculada a IP-MAC, y no hubo colisiones de IP que vi en la tabla DHCP, pero el mismo problema en cada una.

Actualización : he determinado una cosa potencialmente interesante, que es que cuando la clonación de direcciones MAC está desactivada, el puente repetidor deja de funcionar: lo único que puede hacer ping al raspberry pi es el enrutador 2, y no hay conectividad (o acceso al enrutador 1) desde cualquier cosa conectada solo al enrutador 2, incluida la máquina Windows. Sin embargo, la dirección mac que se está clonando es la misma dirección mac que las interfaces del enrutador 2 utilizan de todos modos (de acuerdo con la página de "estado"). He encendido y apagado el enrutador 1 y el enrutador 2 dos veces y no hay diferencia. No entiendo por qué la clonación de direcciones MAC es relevante aquí. Con la clonación de la dirección MAC desactivada, cuando entro en el enrutador, el enrutador puede hacer ping al Raspberry pi, pero no al enrutador 1.

Otra pequeña cosa es que cuando la clonación de direcciones MAC está activada y puedo hacer ping a otras computadoras en la red, arping devuelve la misma dirección mac para cada dispositivo que responde a pings.

Actualización 2: Al verificar los valores de syslog, descubrí que había un mensaje de error relacionado con la dirección 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

Aparentemente, este es un problema conocido que las personas están resolviendo usando la clonación de direcciones MAC. No estoy exactamente seguro de por qué las direcciones MAC aleatorias son un problema y qué otras consecuencias tiene la clonación de direcciones MAC.


Si tiene un cliente inalámbrico al enrutador 2, ¿puede hacer ping desde / hacia la frambuesa al cliente inalámbrico?
MariusMatutiae

Si. Puede hacer ping a la frambuesa desde un cliente inalámbrico en el enrutador 1 o en el enrutador 2.
Paul

En el enrutador 1, ¿tiene habilitado DHCP o dnsmasq?
MariusMatutiae

DHCP sí, no sé sobre dnsmasq. No hay configuración en la interfaz de usuario web en el enrutador 1.
Paul

Es por eso que NAT apesta. Realmente deberías usar WDS en su lugar. (Todos los dispositivos parecen tener la misma dirección MAC porque NAT se está utilizando para convencer al punto de acceso de que está hablando con su cliente).
David Schwartz,

Respuestas:


1

+1 para la descripción detallada del problema.

Como sugerí en el hilo que se abrió en pi frambuesa , se puede comprobar si el router principal aparece en la tabla ARP del RP _: arp -no si tiene instalado el iproute2: ip neigh.

Si es necesario, puede agregar el enrutador en la caché de arp con este comando: arp -s <ROUTER_IP> <ROUTER_MAC>y ver si todavía tiene el problema

También puede verificar si su RPi envía la solicitud ARP como se esperaba olfateando todos los paquetes ARP. En tu RPi, ejecuta:tcpdump arp

También puede ejecutar el mismo comando en el repetidor DD-WRT y en cualquier otro host conectado en el enrutador 1. A medida que se emiten las solicitudes ARP, debería verlas en su LAN.


1

Tuve el mismo problema al instalar el nuevo repetidor Wifi. La solución comprometida es configurar la IP estática para Raspberry Pi.


0

Es difícil de diagnosticar porque, por supuesto, su sistema parece estar configurado correctamente. Por lo tanto, en lugar de pasar por una larga lista de opciones de verificación, te daré algunas ideas para probar.

Una cosa que intentaría es cambiar la puerta de enlace predeterminada al enrutador 2, en lugar del enrutador 1.

Otra cosa es forzar el ping para que se una a la interfaz eth0:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

Estos dos comandos son ligeramente diferentes, ambos deben ser probados. Con suerte, darán diferentes salidas, lo que sería una indicación de una falla.

Luego verificaría / etc / network / interfaces: ¿contiene un par de líneas como

  auto eth0
  iface eth0 inet dhcp

Entonces intentaría reiniciar la interfaz:

  ifdown eth0
  ifup eth0

y luego dhclient nuevamente.

Cuando todo está dicho y hecho, uno debe tener en cuenta que no necesita ser un problema de software. Si visita esta página web , puede leer la siguiente experiencia:

Había pedido otra frambuesa pi y solo volví a crear una imagen de la tarjeta SD, arranqué en esa, e Internet funcionó bien. Saqué la tarjeta SD y la puse en la vieja Raspberry Pi y conecté los mismos cables y el mismo cable de Ethernet, pero todavía no funcionaba ...

Además, debe tener en cuenta que existe la posibilidad de un problema con el cable. Los cables no funcionan / no funcionan objetos. Un problema en RX o TX puede hacer que se caigan muchos cuadros, que la calidad de la señal sea marginal, y así sucesivamente. En este caso, los protocolos como TCP se comportan mejor que ICMP o UDP porque retransmiten paquetes que no han sido recibidos por el destino, lo que le da la impresión incorrecta de una conexión que funciona correctamente. Esta impresión errónea dura hasta que mida la velocidad de conexión, por supuesto.


No hay diferencia entre la respuesta a los dos comandos ping. Lo mismo que pegué arriba. El archivo / etc / network / interfaces está vacío en el caso raspbmc, en el caso raspbian tiene "auto lo" "iface lo inet loopback" "iface eth0 inet dhcp". Reiniciar la interfaz no hace nada en ninguno de los casos. Definitivamente no es un problema con la frambuesa pi, porque tengo dos pis de frambuesa diferentes, ninguno de los cuales funciona cuando está conectado al enrutador 2, pero ambos funcionan cuando está conectado directamente al enrutador 1.
Paul

-1

Problema similar que tuve hace algún tiempo. Mi solución fue editar el /etc/resolv.confarchivo agregando nameserver 8.8.4.4y reiniciando las interfaces usando /etc/init.d/networking restart. Esto funciona para mi.


OP menciona Destination Host Unreachablecomo error, lo que parece sugerir que DNS funciona bien. Un error de DNS habría arrojado algo como cannot resolveo Unknown host.
jornane
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.