Recentemente configurei um roteador WNR2000v3 rodando DD-WRT como uma espécie de ponte repetidora usando a versão "Atheros" doeste tutorial(chamaremos isso de 'roteador 2'), que está repetindo um roteador Medialink Wireless-N (chamaremos isso de 'roteador 1'). Isso funciona perfeitamente para meu telefone Android e computador Windows, tanto por Wi-Fi quanto quando conectado diretamente via Ethernet, mas quando conecto meu Raspberry pi, seja ao executar Raspbian (wheezy) ou Raspbmc, não consigo obter nenhuma conexão fora da rede local.
O raspberry pi pode executar ping (e receber ping) de qualquer outro dispositivo na sub-rede local, incluindo o 'roteador 2', ao qual está conectado diretamente, e é capaz de obter DHCP do roteador 1, mas quando tento e ping roteador 1, recebo "Host de destino inacessível" e, se eu tentar executar ping em qualquer coisa na Internet, como google.com, superuser.com, recebo da mesma forma "Host de destino inacessível".
Aqui está outro computador na rede:
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
Aqui está o roteador 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 é o endereço do 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)
Aqui está a tabela de roteamento:
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
E aqui está a solicitação 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 o resto funciona bem, mas tentei este rapsberry pi com duas imagens diferentes (Raspbmc e raspbian) e dois raspberry pis diferentes e nenhuma configuração funciona. A imagem raspbian foi testada como funcionando quando conectada diretamente ao roteador 1. Este problema parece muito semelhante aesta pergunta sem respostade dois anos atrás, exceto que, nesse caso, parece que ele estava usando wi-fi para o dispositivo que não conseguiu se conectar e, na verdade, estava obtendo alguma conectividade intermitente. Além disso, a resposta do ping veio do roteador, não do dispositivo. O que poderia estar causando este problema?
Editar:Devo também observar que os dois raspberry pis diferentes tinham endereços IP diferentes, um dos quais estava vinculado ao IP-MAC, e não houve colisões de IP que vi na tabela DHCP, mas o mesmo problema em cada um.
Atualizar: Eu determinei uma coisa potencialmente interessante: quando a clonagem de endereço MAC está desativada, a ponte repetidora para de funcionar - a única coisa que pode executar ping no Raspberry Pi é o roteador 2, e não há conectividade (ou acesso ao roteador 1 ) de qualquer coisa conectada apenas ao roteador 2 - incluindo a máquina Windows. No entanto, o endereço mac que está sendo clonado é o mesmo endereço mac que é realmente usado pelas interfaces do roteador 2 (de acordo com a página "status"). Desliguei e liguei o roteador 1 e o roteador 2 duas vezes e isso não faz diferença. Não entendo por que a clonagem de endereços MAC é relevante aqui. Com a clonagem de endereço MAC desativada, quando eu ssh no próprio roteador, o roteador pode executar ping no Raspberry pi, mas não no roteador 1.
Outra pequena coisa é que quando a clonagem de endereço MAC está ativada e eu posso executar ping em outros computadores na rede, o arping retorna o mesmo endereço MAC para cada dispositivo que está respondendo aos pings.
Atualização 2:Ao verificar os valores do syslog, descobri que havia esta mensagem de erro relacionada ao endereço 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 é umproblema conhecidoque as pessoas estão resolvendo usando a clonagem de endereços MAC. Não sei exatamente por que os endereços MAC aleatórios são um problema e quais outras consequências a clonagem de endereços MAC está tendo.
Responder1
+1 para a descrição detalhada do problema.
Como sugeri no tópico que você abriu emRaspberry Pi, você pode verificar se o seu roteador principal está listado na tabela arp do RPi: arp -nou se você tem o iproute2 instalado ip neigh:.
Se necessário, você pode adicionar o roteador no cache arp com este comando: arp -s <ROUTER_IP> <ROUTER_MAC>e ver se ainda tem o problema
Você também pode verificar se o seu RPi envia a solicitação ARP conforme esperado, farejando todos os pacotes ARP. No seu RPi, execute:tcpdump arp
Você também pode executar o mesmo comando no repetidor DD-WRT e em qualquer outro host conectado no roteador 1. À medida que as solicitações ARP são transmitidas, você deverá vê-las em sua LAN.
Responder2
Tive o mesmo problema ao instalar o novo repetidor Wifi. A solução comprometida é definir o IP estático para Raspberry Pi.
Responder3
Este é um problema difícil de diagnosticar, porque é claro que seu sistema parece configurado corretamente. Portanto, em vez de passar por uma longa lista de opções de verificação, darei algumas ideias de coisas para testar.
Uma coisa que eu tentaria é alterar o gateway padrão para o roteador 2, em vez do roteador 1.
Outra coisa é forçar o ping a se vincular à interface eth0:
ping -I 192.168.0.107 192.168.0.1
ping -I eth0 192.168.0.1
Esses dois comandos são ligeiramente diferentes, ambos devem ser tentados. Esperançosamente, eles fornecerão resultados diferentes, o que seria uma indicação de falha.
Então eu verificaria /etc/network/interfaces: ele contém algumas linhas como
auto eth0
iface eth0 inet dhcp
Então eu tentaria reiniciar a interface:
ifdown eth0
ifup eth0
e então dhclient novamente.
No final das contas, deve-se ter em mente que não precisa ser um problema de software. Se você vai paraesta página da Webvocê pode ler a seguinte experiência:
Eu pedi outro Raspberry Pi e apenas recriei a imagem do cartão SD, inicializei naquele e a internet funcionou bem. Tirei o cartão SD e coloquei-o no antigo raspberry pi e conectei exatamente os mesmos cabos e cabo Ethernet, mas ainda não funcionou....
Além disso, você deve ter em mente que existe a possibilidade de haver um problema com o cabo. Os cabos não estão funcionando/objetos que não funcionam. Um problema em RX ou TX pode fazer com que muitos quadros sejam perdidos, a qualidade do sinal seja marginal e assim por diante. Nesse caso, protocolos como TCP se comportam melhor que ICMP ou UDP porque retransmitem pacotes que não foram recebidos pelo destino, dando a impressão errada de uma conexão funcionando corretamente. Essa impressão errada dura até você medir a velocidade da conexão, é claro.
Responder4
Problema semelhante que tive há algum tempo. Minha solução foi editar
/etc/resolv.confo arquivo adicionando nameserver 8.8.4.4e reiniciando interfaces usando /etc/init.d/networking restart. Funciona para mim.