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.