Raspberry pi не може пінг-маршрутизатора чи Інтернет-адреси по мосту Wi-Fi


10

Нещодавно я встановив маршрутизатор WNR2000v3, на якому працює DD-WRT, як своєрідний міст-ретранслятор, використовуючи версію "Atheros" цього підручника (це будемо називати "маршрутизатором 2"), який повторює маршрутизатор Medialink Wireless-N (ми ' Я зателефоную цьому "маршрутизатору 1"). Це ідеально підходить для мого телефону з Android та комп'ютерами Windows як через Wi-Fi, так і під час прямого підключення через Ethernet, але коли я підключаю до свого Raspberry pi, під час роботи Raspbian (wheezy) або Raspbmc, я не можу отримати з'єднання поза локальною мережею.

Малиновий пі може пінговувати (і пінгнути) будь-який з інших пристроїв локальної підмережі, включаючи "маршрутизатор 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) та двома різними малиновими пішами та без конфігурації. Зображення raspbian було перевірено як робоче при безпосередньому підключенні до маршрутизатора 1. Ця проблема здається дуже схожою на це питання без відповіді від двох років тому, за винятком того, що в такому випадку здається, що він використовував wifi для пристрою, який не вдалося підключитися, і він насправді отримував деяку переривчасту зв’язок. Також відповідь ping була від маршрутизатора, а не від пристрою. Що може спричинити цю проблему?

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

Оновлення : я визначив одну потенційно цікаву річ, а саме: коли клонування MAC-адреси вимкнено, мост ретранслятора перестає функціонувати - єдине, що може пінгнути малиновий пі - це маршрутизатор 2, і немає підключення (або доступу до маршрутизатора 1) від усього, що підключено лише до маршрутизатора 2 - включаючи машину Windows. Однак mac-адреса, яку клонують, - це та сама адреса mac, яка фактично використовується інтерфейсами маршрутизатора 2 у будь-якому випадку (відповідно до сторінки "статус"). У мене два рази перемикали живлення як маршрутизатор 1, так і маршрутизатор 2, і це не має ніякого значення. Я не розумію, чому клонування MAC-адрес тут є актуальним. При відключенні MAC-адреси, коли я впадаю в сам маршрутизатор, маршрутизатор може пінг-програмувати Raspberry pi, але не маршрутизатор 1.

Ще одна невелика річ - це те, що коли клонування MAC-адреси увімкнено, і я можу насправді пінгнути інші комп’ютери в мережі, arping повертає ту саму мак-адресу для кожного пристрою, який відповідає на pings.

Оновлення 2: Перевіряючи значення syslog, я виявив, що це повідомлення про помилку стосується 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, чи можете ви пінг до / з малинового до бездротового клієнта?
MariusMatutiae

Так. Ви можете попросити малину від бездротового клієнта на маршрутизаторі 1 або маршрутизаторі 2.
Павло

На маршрутизаторі 1 увімкнено DHCP або dnsmasq?
MariusMatutiae

DHCP так, я не знаю про dnsmasq. У веб-інтерфейсі на маршрутизаторі 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

У мене була така ж проблема при установці нового Wi-Fi повторювача. Компрометоване рішення встановлюється статичним 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

а потім знову dhclient.

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

Я замовив черговий малиновий пі та просто переробив SD-карту, завантажився в цю, і Інтернет працював чудово. Я вийняв sd карту і поклав її в старий малиновий пі та підключив такі ж точні кабелі та мережевий шнур, але він все ще не працював ....

Також слід пам’ятати, що існує можливість виникнення проблеми з кабелем. Кабелі не працюють / не працюють. Проблема в RX або TX може спричинити падіння багатьох кадрів, якість сигналу маргінальна тощо. У цьому випадку такі протоколи, як TCP, поводяться краще, ніж ICMP або UDP, тому що вони повторно передають пакети, які не були отримані ціллю, створюючи неправильне враження про належно працююче з'єднання. Це неправильне враження триває, доки, звичайно, не виміряти швидкість з'єднання.


Немає різниці між відповіддю на дві команди ping. Те саме, що я вклеював вище. Файл / etc / network / interfaces порожній у випадку raspbmc, у випадку raspbian є "auto lo" "iface lo inet loopback" "iface eth0 inet dhcp". Перезапуск інтерфейсу нічого не робить в будь-якому випадку. З малиновим пі - це точно не проблема, тому що у мене є дві різні малинові піски, жодна з яких не працює, коли підключено до маршрутизатора 2, але обидва працюють під час підключення безпосередньо до маршрутизатора 1.
Павло

-1

Подібна проблема у мене була деякий час тому. Моє рішення - редагування /etc/resolv.confфайлів шляхом додавання nameserver 8.8.4.4та перезавантаження інтерфейсів за допомогою /etc/init.d/networking restart. Це працює для мене.


ОП згадує Destination Host Unreachableяк помилку, яка, начебто, говорить про те, що DNS працює чудово. Помилка DNS призведе до чогось подібного cannot resolveабо Unknown host.
jornane
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.