Recentemente, configurei um roteador WNR2000v3 executando o DD-WRT como uma espécie de ponte repetidora usando a versão "Atheros" deste tutorial (chamaremos de 'roteador 2'), que está repetindo um roteador Medialink Wireless-N (nós ' chamamos isso de 'roteador 1'). Isso funciona perfeitamente para o meu telefone Android e o computador com Windows tanto pelo Wi-Fi quanto quando conectado diretamente via Ethernet, mas quando conecto meu Raspberry pi, ao executar Raspbian (wheezy) ou Raspbmc, não consigo obter nenhuma conexão fora da rede local.
O raspberry pi pode executar ping (e ser executado por) por qualquer um dos outros dispositivos na sub-rede local, incluindo o 'roteador 2', no qual está diretamente conectado, e pode obter o DHCP do roteador 1, mas quando tento ping roteador 1, recebo "Host de destino inacessível" e, se eu tentar executar ping na Internet, como google.com, superuser.com, também recebo "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.
Tudo o resto funciona bem, mas eu tentei esse rapsberry pi com duas imagens diferentes (Raspbmc e raspbian) e dois pis de framboesa diferentes e nenhuma configuração funciona. A imagem raspbian foi testada como funcionando quando conectada diretamente ao roteador 1. Esse problema parece muito semelhante a essa pergunta sem resposta de dois anos atrás, exceto que, nesse caso, parece que ele estava usando wifi para o dispositivo que não conseguiu se conectar e ele estava realmente tendo alguma conectividade intermitente. Também a resposta de ping do roteador, não do dispositivo. O que poderia estar causando este problema?
Edit: Devo também observar que os dois diferentes raspberry pis tinham endereços IP diferentes, um dos quais era vinculado ao IP-MAC, e não havia colisões de IP que eu vi na tabela DHCP, mas o mesmo problema em cada um.
Atualização : determinei uma coisa potencialmente interessante: quando a Clonagem de Endereço MAC é desativada, a ponte repetidora deixa 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 realmente usado pelas interfaces do roteador 2 (de acordo com a página "status"). Eu desliguei 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 ssh no próprio roteador, ele pode executar ping no Raspberry pi, mas não no roteador 1.
Outra coisa pequena é 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 todos os dispositivos que respondem a 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, esse é um problema conhecido que as pessoas estão solucionando 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 conseqüências a clonagem de endereços MAC está tendo.
fonte
Respostas:
+1 para a descrição detalhada do problema.
Como sugeri no segmento você abriu na pi framboesa , você pode verificar se o seu roteador principal é listado na tabela ARP do RPI:
arp -nou se você tiver 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 veja se você ainda tem o problemaVocê também pode verificar se o seu RPi envia a solicitação ARP conforme o esperado, farejando todos os pacotes ARP. No seu RPi, execute:
tcpdump arpVocê também pode executar o mesmo comando no repetidor DD-WRT e em qualquer outro host conectado no roteador 1. Como as solicitações de ARP são transmitidas, você deve vê-las na sua LAN.
fonte
Eu tive o mesmo problema ao instalar o novo Wifi Repeater. A solução comprometida é definida como o IP estático para o Raspberry Pi.
fonte
Esse é um procedimento 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 idéias para testar.
Uma coisa que eu tentaria é mudar o gateway padrão para o roteador 2, em vez do roteador 1.
Outra coisa é forçar o ping a se ligar à interface eth0:
Esses dois comandos são ligeiramente diferentes, ambos devem ser tentados. Felizmente, eles fornecerão saídas diferentes, o que seria uma indicação de uma falha.
Então eu verificaria / etc / network / interfaces: ele contém algumas linhas como
Então eu tentaria reiniciar a interface:
e depois dhclient novamente.
Quando tudo estiver dito e feito, deve-se ter em mente que não precisa ser um problema de software. Se você acessar esta página da Web, poderá ler a seguinte experiência:
Além disso, lembre-se de que existe a possibilidade de um problema com o cabo. Os cabos não estão funcionando / não estão funcionando objetos. Um problema no 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 o TCP se comportam melhor que o ICMP ou o UDP porque eles 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.
fonte
Problema semelhante que tive há algum tempo. Minha solução foi editar
/etc/resolv.confarquivos adicionandonameserver 8.8.4.4e reiniciando interfaces usando/etc/init.d/networking restart. Funciona para mim.fonte
Destination Host Unreachablecomo erro, o que parece sugerir que o DNS funciona bem. Um erro de DNS teria produzido algo comocannot resolveouUnknown host.