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.
fuente
Respuestas:
+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 problemaTambién puede verificar si su RPi envía la solicitud ARP como se esperaba olfateando todos los paquetes ARP. En tu RPi, ejecuta:
tcpdump arpTambié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.
fuente
Tuve el mismo problema al instalar el nuevo repetidor Wifi. La solución comprometida es configurar la IP estática para Raspberry Pi.
fuente
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:
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
Entonces intentaría reiniciar la interfaz:
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:
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.
fuente
Problema similar que tuve hace algún tiempo. Mi solución fue editar el
/etc/resolv.confarchivo agregandonameserver 8.8.4.4y reiniciando las interfaces usando/etc/init.d/networking restart. Esto funciona para mi.fuente
Destination Host Unreachablecomo error, lo que parece sugerir que DNS funciona bien. Un error de DNS habría arrojado algo comocannot resolveoUnknown host.