9

Недавно я настроил маршрутизатор 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-адресов.

4 ответа4

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 транслируются, вы должны видеть их через свою локальную сеть.

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

-1

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .