私は最近、DD-WRTを実行するWNR2000v3ルーターを「Atheros」バージョンのリピーターブリッジとしてセットアップしました。このチュートリアル(これを「ルーター 2」と呼びます) は、Medialink Wireless-N ルーター (これを「ルーター 1」と呼びます) をリピートしています。これは、WiFi 経由とイーサネット経由で直接接続の両方で、Android フォンと Windows コンピューターで完璧に機能しますが、Raspbian (wheezy) または Raspbmc を実行しているときに Raspberry pi を接続すると、ローカル ネットワークの外部に接続できなくなります。
Raspberry Pi は、直接接続されている「ルーター 2」を含む、ローカル サブネット上の他のデバイスに ping を実行でき (また、ping を実行され)、ルーター 1 から DHCP を取得できますが、ルーター 1 に ping を実行しようとすると、「宛先ホストに到達できません」というメッセージが表示されます。また、google.com、superuser.com など、インターネット上の任意の場所に ping を実行しようとすると、同様に「宛先ホストに到達できません」というメッセージが表示されます。
ネットワーク上の別のコンピューターは次のとおりです。
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.
それ以外は問題なく動作しますが、このRaspberry Piを2つの異なるイメージ（Raspbmcとraspbian）と2つの異なるRaspberry Piで試してみましたが、設定は機能しませんでした。Raspbianイメージは、ルータ1に直接接続したときに動作することがテストされています。この問題は、この答えのない質問2 年前のものですが、その場合は、接続に失敗したデバイスに Wi-Fi を使用していたようで、実際には接続が断続的でした。また、ping 応答はデバイスではなくルーターからのものでした。この問題の原因は何でしょうか?
編集：また、2 台の異なる Raspberry Pi には異なる IP アドレスがあり、そのうちの 1 つは IP-MAC バインドされており、DHCP テーブルで確認された IP 衝突は発生しなかったものの、それぞれで同じ問題が発生したことにも注意してください。
アップデート: 興味深い点が 1 つ判明しました。MAC アドレスの複製がオフになっていると、リピータ ブリッジが機能しなくなります。Raspberry Pi に ping できるのはルータ 2 のみで、ルータ 2 にのみ接続されているもの (Windows マシンを含む) からは接続 (またはルータ 1 へのアクセス) ができません。ただし、複製されている MAC アドレスは、ルータ 2 のインターフェイスで実際に使用されている MAC アドレスと同じです (「ステータス」ページによると)。ルータ 1 とルータ 2 の両方の電源を 2 回オン/オフしましたが、違いはありません。MAC アドレスの複製がここで関係する理由がわかりません。MAC アドレスの複製がオフになっていると、ルータ自体に SSH で接続すると、ルータは Raspberry Pi に ping できますが、ルータ 1 には ping できません。
もう 1 つ小さなことは、MAC アドレスの複製がオンになっていて、実際にネットワーク上の他のコンピューターに ping を実行できる場合、arping は ping に応答するすべてのデバイスに対して同じ MAC アドレスを返すことです。
アップデート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 アドレスの複製によって他にどのような影響があるのかはよくわかりません。
答え1
詳細な問題の説明に +1 です。
あなたが開いたスレッドで私が示唆したようにラズベリーパイメイン ルータが RPi の arp テーブルにリストされているかどうか、arp -nまたは iproute2 がインストールされているかどうかを確認できますip neigh。
必要であれば、次のコマンドでルーターをARPキャッシュに追加しarp -s <ROUTER_IP> <ROUTER_MAC>、問題が解決するかどうかを確認してください。
すべての ARP パケットをスニッフィングすることで、RPi が期待どおりに ARP 要求を送信しているかどうかを確認することもできます。RPi で、次のコマンドを実行します。tcpdump arp
DD-WRT リピーターとルータ 1 に接続されている他のホストで同じコマンドを実行することもできます。ARP 要求がブロードキャストされると、LAN 全体でそれらが表示されるはずです。
答え2
新しい Wi-Fi リピーターをインストールするときにも同じ問題が発生しました。妥協した解決策は、Raspberry Pi に静的 IP を設定することです。
答え3
これは診断が難しい問題です。もちろん、システムは正しく構成されているように見えるからです。そのため、チェック オプションの長いリストを確認するのではなく、テストすべき項目のアイデアをいくつか紹介します。
試してみたいことの 1 つは、デフォルト ゲートウェイをルータ 1 ではなくルータ 2 に変更することです。
もう 1 つは、ping をインターフェイス eth0 に強制的にバインドすることです。
ping -I 192.168.0.107 192.168.0.1
ping -I eth0 192.168.0.1
これら 2 つのコマンドは若干異なるため、両方を試してみる必要があります。うまくいけば、異なる出力が得られ、それが障害の兆候となるでしょう。
次に、/etc/network/interfacesを確認します。次のような行が含まれていますか？
auto eth0
iface eth0 inet dhcp
次に、インターフェースを再起動してみます。
ifdown eth0
ifup eth0
そしてもう一度 dhclient を実行します。
結局のところ、それは必ずしもソフトウェアの問題ではないということを覚えておく必要があります。このウェブページ次のような体験談を読むことができます。
私は別のラズベリーパイを注文し、SD カードのイメージを再作成して、そのラズベリーパイで起動したところ、インターネットは正常に動作しました。SD カードを取り出して古いラズベリーパイに挿入し、まったく同じケーブルとイーサネット コードを接続しましたが、それでも動作しませんでした...
また、ケーブルに問題がある可能性もあることを念頭に置いておく必要があります。ケーブルは機能していない/機能していないオブジェクトです。RX または TX に問題があると、多くのフレームがドロップされたり、信号品質が限界に達したりする可能性があります。この場合、TCP などのプロトコルは、ターゲットで受信されていないパケットを再送信するため、ICMP や UDP よりも適切に動作し、接続が正常に機能しているという誤った印象を与えます。もちろん、この誤った印象は、接続速度を測定するまで続きます。
答え4
以前、私も同じような問題に遭遇しました。私の解決策は、
/etc/resolv.confを追加してファイルを編集しnameserver 8.8.4.4、 を使用してインターフェースを再起動することでした/etc/init.d/networking restart。私の場合はこれでうまくいきました。