☰

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

tag-icon • tag-icon networking router dd-wrt raspberry-pi
Raspberry Pi не может пинговать маршрутизатор или интернет-адреса через мост Wi-Fi

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

Raspberry Pi может пинговать (и получать пинг от) любое другое устройство в локальной подсети, включая «маршрутизатор 2», к которому он напрямую подключен, и может получать DHCP от маршрутизатора 1, но когда я пытаюсь пинговать маршрутизатор 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) и двумя разными raspberry pi, и ни одна конфигурация не работает. Образ raspbian был протестирован как рабочий при прямом подключении к Router 1. Эта проблема кажется очень похожей наэтот вопрос без ответадвухлетней давности, за исключением того, что в этом случае он, похоже, использовал Wi-Fi для устройства, которое не удалось подключить, и он действительно получал прерывистое соединение. Также ответ на пинг там был от маршрутизатора, а не от устройства. Что может быть причиной этой проблемы?

Редактировать:Я также должен отметить, что два разных Raspberry Pi имели разные IP-адреса, один из которых был привязан к IP-MAC, и в таблице DHCP я не увидел никаких коллизий IP-адресов, но на каждом из них наблюдалась одна и та же проблема.

Обновлять: Я определил одну потенциально интересную вещь, а именно, что когда клонирование 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-адресов.

решение1

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

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

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

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

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

решение2

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

решение3

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

Я бы попробовал изменить шлюз по умолчанию на маршрутизатор 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

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

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

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

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

решение4

Похожая проблема у меня была некоторое время назад. Решением было редактирование /etc/resolv.confфайла путем добавления nameserver 8.8.4.4, и перезапуск интерфейсов с помощью /etc/init.d/networking restart. У меня это работает.

Связанный контент