Recientemente configuré un enrutador WNR2000v3 que ejecuta DD-WRT como una especie de puente repetidor usando la versión "Atheros" deeste tutorial(lo llamaremos 'enrutador 2'), que repite un enrutador Medialink Wireless-N (lo llamaremos 'enrutador 1'). Esto funciona perfectamente para mi teléfono Android y computadora con Windows tanto a través de wifi como cuando estoy conectado 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.
La Raspberry Pi puede hacer ping (y recibir ping de) cualquiera de los otros dispositivos en la subred local, incluido el 'enrutador 2', al que está conectado directamente, y puede obtener DHCP del enrutador 1, pero cuando intento y Al hacer ping al enrutador 1, aparece "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 la 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 probé esta Raspberry Pi con dos imágenes diferentes (Raspbmc y Raspbian) y dos Raspberry Pi diferentes y no funciona ninguna configuración. Se ha probado que la imagen de Raspbian funciona cuando se conecta directamente al enrutador 1. Este problema parece muy similar aesta pregunta sin respuestade hace dos años, excepto que en ese caso parece que estaba usando wifi para el dispositivo que no pudo conectarse, y en realidad estaba obteniendo conectividad intermitente. Además, la respuesta de ping provino del enrutador, no del dispositivo. ¿Qué podría estar causando este problema?
Editar:También debo tener en cuenta que los dos Raspberry Pi diferentes tenían diferentes direcciones IP, una de las cuales estaba vinculada a IP-MAC, y no vi colisiones de IP en la tabla DHCP, pero sí el mismo problema en cada una.
Actualizar: He determinado una cosa potencialmente interesante, que es que cuando se desactiva la clonación de direcciones MAC, el puente repetidor deja de funcionar; lo único que puede hacer ping a la Raspberry Pi es el enrutador 2, y no hay conectividad (ni acceso al enrutador 1). ) desde cualquier cosa conectada únicamente al enrutador 2, incluida la máquina con Windows. Sin embargo, la dirección mac que se está clonando es la misma dirección mac que realmente utilizan las interfaces del enrutador 2 de todos modos (según la página de "estado"). He reiniciado 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 al enrutador, el enrutador puede hacer ping a la 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 los pings.
Actualización 2:Al verificar los valores de syslog, descubrí que había este 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 esto es unproblema conocidoque la gente está resolviendo mediante 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.
Respuesta1
+1 para la descripción detallada del problema.
Como sugerí en el hilo que abriste enframbuesa pi, puede verificar si su enrutador principal figura en la tabla arp del RPi: arp -no si tiene iproute2 instalado ip neigh:.
Si es necesario, puede agregar el enrutador en el caché arp con este comando: arp -s <ROUTER_IP> <ROUTER_MAC>y vea si aún tiene el problema
También puede verificar si su RPi envía la solicitud ARP como se esperaba rastreando 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 al enrutador 1. A medida que se transmiten las solicitudes ARP, debería verlas en su LAN.
Respuesta2
Tuve el mismo problema al instalar un nuevo repetidor Wifi. La solución comprometida es configurar la IP estática para Raspberry Pi.
Respuesta3
Este es un problema complicado de diagnosticar porque, por supuesto, su sistema parece estar configurado correctamente. Entonces, en lugar de revisar una larga lista de opciones de verificación, le daré algunas ideas sobre cosas que puede 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 que ping se vincule 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, se deben probar ambos. Con suerte, darán resultados diferentes, lo que sería un indicio de una falla.
Luego comprobaría /etc/network/interfaces: ¿contiene un par de líneas como
auto eth0
iface eth0 inet dhcp
Luego intentaría reiniciar la interfaz:
ifdown eth0
ifup eth0
y luego dhclient nuevamente.
Al fin y al cabo, hay que tener en cuenta que no tiene por qué ser un problema de software. Si vas aesta pagina webPuedes leer la siguiente experiencia:
Pedí otra Raspberry Pi y simplemente volví a crear una imagen de la tarjeta SD, la inicié e Internet funcionó bien. Saqué la tarjeta SD y la puse en la vieja Raspberry Pi y conecté exactamente los mismos cables y el cable Ethernet, pero todavía no funcionó...
Además, debes tener en cuenta que existe la posibilidad de que haya algún problema con el cable. Los cables no funcionan/objetos que no funcionan. Un problema en RX o TX puede provocar que se pierdan muchos fotogramas, que la calidad de la señal sea marginal, etc. En este caso, protocolos como TCP se comportan mejor que ICMP o UDP porque retransmiten paquetes que no han sido recibidos por el destino, dando la impresión equivocada de una conexión que funciona correctamente. Esta impresión errónea, por supuesto, dura hasta que se mide la velocidad de conexión.
Respuesta4
Un problema similar tuve hace algún tiempo. Mi solución fue editar
/etc/resolv.confel archivo agregando nameserver 8.8.4.4y reiniciando las interfaces usando /etc/init.d/networking restart. Esto funciona para mi.