Raspberry pi не может пропинговать маршрутизатор или интернет-адреса через мост wifi

10

Недавно я настроил маршрутизатор WNR2000v3, на котором запущен DD-WRT, в качестве своего рода моста повторителя, используя версию этого руководства «Atheros» (назовем это «маршрутизатор 2»), которая повторяет маршрутизатор Medialink Wireless-N (мы Я буду называть это «маршрутизатор 1»). Это прекрасно работает для моего телефона Android и компьютера Windows как через Wi-Fi, так и при прямом подключении через Ethernet, но когда я подключаю свой Raspberry Pi, либо при запуске Raspbian (wheezy) или Raspbmc, я не могу получить никакого соединения вне локальной сети.

Raspberry Pi может пинговать (и пинговать) любые другие устройства в локальной подсети, включая «маршрутизатор 2», к которому он напрямую подключен, и он может получить DHCP от маршрутизатора 1, но когда я пытаюсь и маршрутизатор ping 1, я получаю «Целевой хост недоступен», и если я пытаюсь пинговать что-либо в Интернете, например, google.com, superuser.com, я также получаю «Целевой хост недоступен».

Вот еще один компьютер в сети:

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

Вот маршрутизатор 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 - это адрес 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)

Вот таблица маршрутизации:

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

И вот запрос 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.

Все остальное работает нормально, но я попробовал этот rapsberry pi с двумя разными образами (Raspbmc и raspbian) и двумя разными малиновыми писами, и конфигурация не работает. Распбийский образ был протестирован как работающий при прямом подключении к маршрутизатору 1. Эта проблема кажется очень похожей на этот вопрос, оставшийся без ответа два года назад, за исключением того, что в этом случае кажется, что он использовал Wi-Fi для устройства, которое не удалось подключиться, и он фактически получал некоторую прерывистую связь. Также ответ на пинг был от роутера, а не от устройства. Что может быть причиной этой проблемы?

Изменить: я также должен отметить, что два разных малиновый pis имели разные IP-адреса, один из которых был связан с IP-MAC, и не было никаких IP-коллизий, которые я видел в таблице DHCP, но та же проблема на каждом.

Обновление : я определил одну потенциально интересную вещь, которая заключается в том, что, когда клонирование MAC-адреса отключено, мост повторителя перестает функционировать - единственное, что может пропинговать Raspberry Pi, это маршрутизатор 2, и нет подключения (или доступа к маршрутизатору). 1) из всего, что подключено только к маршрутизатору 2 - включая машину Windows. Однако клонируемый MAC-адрес - это тот же Mac-адрес, который фактически используется интерфейсами маршрутизатора 2 (в соответствии со страницей «status»). Я дважды включил питание маршрутизатора 1 и маршрутизатора 2, и это не имеет значения. Я не понимаю, почему клонирование MAC-адресов здесь актуально. Когда клонирование MAC-адреса отключено, когда я запускаю ssh в самом маршрутизаторе, маршрутизатор может пропинговать Raspberry pi, но не маршрутизатор 1.

Еще одна небольшая вещь заключается в том, что когда клонирование MAC-адреса включено, и я могу на самом деле пинговать другие компьютеры в сети, arping возвращает один и тот же mac-адрес для каждого устройства, которое отвечает на пинги.

Обновление 2: при проверке значений системного журнала я обнаружил, что это сообщение об ошибке относится к 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

Очевидно, это известная проблема, которую люди решают с помощью клонирования MAC-адресов. Я не совсем уверен, почему случайные MAC-адреса являются проблемой, и каковы другие последствия клонирования MAC-адресов.

Павел
источник
Если у вас есть беспроводной клиент к маршрутизатору 2, можете ли вы пропинговать Rasberry к беспроводному клиенту?
MariusMatutiae
Да. Вы можете пропинговать малину от беспроводного клиента на маршрутизаторе 1 или маршрутизаторе 2.
Paul
На маршрутизаторе 1 у вас включен DHCP или dnsmasq?
MariusMatutiae
DHCP да, я не знаю о dnsmasq. Там нет настройки для этого в webUI на маршрутизаторе 1.
Пол
Вот почему NAT отстой. Вы должны действительно использовать WDS вместо этого. (Кажется, что каждое устройство имеет одинаковый MAC-адрес, потому что NAT используется для убеждения точки доступа в том, что она разговаривает со своим клиентом.)
David Schwartz

Ответы:

1

+1 за подробное описание проблемы.

Как я предложил на резьбе вы открыли в Raspberry Pi , вы можете проверить , если ваш главный маршрутизатор перечислены в таблице агр ИРЦ в: arp -nили , если у вас установлен iproute2: ip neigh.

При необходимости вы можете добавить маршрутизатор в кэш arp с помощью этой команды: arp -s <ROUTER_IP> <ROUTER_MAC>и посмотреть, если проблема не устранена

Вы также можете проверить, отправляет ли ваш RPi запрос ARP, как ожидалось, прослушивая все пакеты ARP. На вашем RPi запустите:tcpdump arp

Вы также можете выполнить ту же команду на ретрансляторе DD-WRT и на любом другом хосте, подключенном к маршрутизатору 1. Поскольку запросы ARP транслируются, вы должны видеть их по локальной сети.

Рипат
источник
1

У меня была такая же проблема при установке нового повторителя Wifi. Скомпрометированное решение устанавливает статический IP для Raspberry Pi.

Лам До
источник
0

Это сложно диагностировать, потому что, конечно, ваша система настроена правильно. Поэтому вместо того, чтобы идти по длинному списку вариантов проверки, я дам вам несколько идей для того, что нужно проверить.

Я бы попробовал изменить шлюз по умолчанию на маршрутизатор 2, а не на маршрутизатор 1.

Другое дело, чтобы ping привязывался к интерфейсу eth0:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

Эти две команды немного отличаются, обе должны быть опробованы. Надеемся, что они будут давать разные выходы, которые будут указывать на ошибку.

Тогда я бы проверил / etc / network / interfaces: он содержит пару строк, например

  auto eth0
  iface eth0 inet dhcp

Затем я попытался бы перезапустить интерфейс:

  ifdown eth0
  ifup eth0

и затем снова.

Когда все сказано и сделано, следует помнить, что это не должно быть проблемой программного обеспечения. Если вы перейдете на эту веб-страницу, вы можете прочитать следующую информацию:

Я заказал еще один малиновый пи и просто перерисовал SD-карту, загрузился в нее, и интернет работал нормально. Я вынул SD-карту и вставил ее в старый Raspberry Pi и подключил те же самые кабели и кабель Ethernet, но она все еще не работала ....

Кроме того, вы должны иметь в виду, что существует проблема с кабелем. Кабели не работают / не работают объекты. Проблема в RX или TX может привести к тому, что многие кадры будут отброшены, качество сигнала будет предельным и так далее. В этом случае протоколы, такие как TCP, ведут себя лучше, чем ICMP или UDP, потому что они повторно передают пакеты, которые не были получены целью, создавая неправильное представление о правильно работающем соединении. Это неправильное впечатление длится до тех пор, пока вы не измерите скорость соединения, конечно.

MariusMatutiae
источник
Нет разницы между ответом на две команды ping. То же, что я вставил выше. Файл / etc / network / interfaces является пустым в случае raspbmc, в случае raspbian имеет значение «auto lo», «iface lo inet loopback», «iface eth0 inet dhcp». Перезапуск интерфейса ничего не делает в любом случае. Это точно не проблема с Raspberry Pi, потому что у меня есть два разных Raspberry Pis, ни один из которых не работает при подключении к маршрутизатору 2, но оба работают при подключении непосредственно к маршрутизатору 1.
Пол
-1

Подобная проблема у меня была некоторое время назад. Моим решением было редактирование /etc/resolv.confфайла путем добавления nameserver 8.8.4.4и перезапуска интерфейсов с использованием /etc/init.d/networking restart. Меня устраивает.

Мубин
источник
OP упоминает Destination Host Unreachableкак ошибку, которая, кажется, предполагает, что DNS работает нормально. Ошибка DNS привела бы к чему-то вроде cannot resolveили Unknown host.
Йорн