Raspberry pi não pode fazer ping em endereços de roteador ou internet por ponte wifi

9

Eu configurei recentemente um roteador WNR2000v3 executando o DD-WRT como uma espécie de ponte repetidora usando a versão "Atheros" do este tutorial (chamaremos isso de 'roteador 2'), que está repetindo um roteador Medialink Wireless-N (chamaremos isso de 'roteador 1'). Isso funciona perfeitamente para o meu telefone Android e Windows tanto no Wi-Fi e quando conectado diretamente via Ethernet, mas quando eu ligar meu Raspberry pi, quando executando Raspbian (wheezy) ou Raspbmc, não consigo obter qualquer conexão fora da rede local.

O raspberry pi pode pingar (e receber ping) de qualquer outro dispositivo na sub-rede local, incluindo o 'roteador 2', no qual ele está diretamente conectado, e é capaz de obter DHCP do roteador 1, mas quando Eu tento e pingar o roteador 1, recebo "Destination Host Unreachable", e se eu tentar pingar qualquer coisa na internet como google.com, superuser.com, eu da mesma forma recebo "Destination Host Unreachable".

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 do 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 este rapsberry pi com duas imagens diferentes (Raspbmc e raspbian) e dois pispers 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 não respondida 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 obtendo alguma conectividade intermitente. Além disso, a resposta do ping estava no roteador, não no dispositivo. O que poderia estar causando esse problema?

Edit: Devo notar também que os dois diferentes raspberry pis tinham endereços IP diferentes, um dos quais era IP-MAC ligado, e não havia colisões de IP que eu vi na tabela DHCP, mas o mesmo problema em cada um.

Atualização : Eu determinei uma coisa potencialmente interessante, que é quando a clonagem de endereços MAC está desativada, a ponte do repetidor deixa de funcionar - a única coisa que pode fazer ping no pi do raspberry é 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 qualquer maneira (de acordo com a página "status"). Eu tenho ciclo de energia tanto o roteador 1 e roteador 2 duas vezes e não faz diferença. Eu não entendo porque a clonagem de endereços MAC é relevante aqui. Com o endereço MAC clonado, quando eu ssh no próprio roteador, o roteador pode fazer ping no Raspberry pi, mas não no roteador 1.

Outra coisa pequena é que quando a clonagem de endereços MAC está ativada e eu posso pingar outros computadores na rede, o arping retorna o mesmo endereço mac para cada dispositivo que está respondendo a pings.

Atualização 2: Ao verificar os valores do syslog, descobri que havia uma 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 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.

    
por Paul 29.11.2013 / 09:19

4 respostas

1

+1 para a descrição detalhada do problema.

Como sugeri no tópico que você abriu em raspberry pi , você pode verificar se o seu roteador principal está listado na tabela arp do RPi: arp -n ou se você tem o iproute2 instalado: ip neigh .

Se necessário, você pode adicionar o roteador no cache do arp com este comando: arp -s <ROUTER_IP> <ROUTER_MAC> e ver se você 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. Como as solicitações ARP são transmitidas, você deve vê-las na sua rede.

    
por 11.12.2013 / 07:21
1

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.

    
por 19.06.2016 / 07:45
0

Este é complicado de diagnosticar, porque é claro que seu sistema parece estar corretamente configurado. Assim, em vez de passar por uma longa lista de opções de verificação, darei algumas ideias para as coisas testarem.

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 ligar-se à interface eth0:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

Estes dois comandos são ligeiramente diferentes, ambos devem ser tentados. Com sorte, eles vão dar saídas diferentes, o que seria uma indicação de uma falha.

Em seguida, eu verificaria o / 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, em seguida, 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:

I had ordered another raspberry pi and just re-imaged the sd card, booted up in that one, and the internet worked fine. I took the sd card out and put it in the old raspberry pi and hooked up the same exact cables and ethernet cord but it still didn't work....

Além disso, você deve ter em mente que existe a possibilidade de um problema com o cabo. Os cabos não estão funcionando / não estão trabalhando objetos. Um problema no RX ou no TX pode fazer com que muitos quadros sejam descartados, a qualidade do sinal seja marginal e assim por diante. Nesse caso, protocolos como o TCP se comportam melhor do que o ICMP ou o UDP, pois eles retransmitem pacotes que não foram recebidos pelo destino, dando a impressão errada de uma conexão que está funcionando corretamente. Essa impressão errada dura até você medir a velocidade de conexão, é claro.

    
por 29.11.2013 / 10:58
-1

Problema semelhante que tive há algum tempo. Minha solução foi editar /etc/resolv.conf , adicionando nameserver 8.8.4.4 e reiniciando interfaces usando /etc/init.d/networking restart . Isso funciona para mim.

    
por 23.07.2015 / 22:22