WiFiレンジエクステンダー、および失敗したARP要求

1

以下に概説するように、BT HomeHub 5とNetgear EX6150 WiFiエクステンダーのネットワークで作業しています。ネットワークには他のポイントもありますが、簡潔にするために省略しました。ピンクの破線はすべてWiFiです。

ネットワーク図

私が見ている問題は、PC 1 は PC 2と通信できない（しない）が、私の電話は通信できるということです。もちろん、私の電話は、エクステンダーに直接飛び乗って接続する機能を備えており、現在のところ、ここでその役割を果たしていると断言することはできません。

同じ状況は、PC 1がWiFiエクステンダー上の他のホストと通信しようとしていることを表しています。

すべてのホストがインターネットにアクセスできます。

エクステンダーがMACアドレスを「変更」することを発見しましたが、その理由を理解することはできません。たとえば、PC 2のMACアドレスは88:b1:11:f4:e0:66ですが、ルーターのインターフェイス（およびルーターに接続されているホスト）は、として通信することを確認します02:0f:b5:f4:e0:66。マニュアルには33ページにひどく書かれたセクションがあり、それをオフにする方法はないようです。この技術的な理由はわかりません。現在、これが問題の重要な部分であることに賭けています。

技術的なビットの時間。

  • PC 1は192.168.1.74/ 1c:3e:84:c8:0c:08（OSによって報告される）
  • PC 2は192.168.1.16/ 88:b1:11:f4:e0:66（OSによって報告される）

私の電話は、（Fingを使用して）ネットワークを陽気にスキャンし、ホストを発見し、それをpingします...前述のように、PC 1はそうしません。

私はPC 2のアドレス情報をPC 1のARPテーブルに手動で追加しようとしました。

C:\WINDOWS\system32>netsh interface ip add neighbors 14 192.168.1.16 02-0f-b5-f4-e0-66


C:\WINDOWS\system32>arp -a

Interface: 192.168.1.74 --- 0xe
  Internet Address      Physical Address      Type
  ...
  192.168.1.16          02-0f-b5-f4-e0-66     static
  ...

C:\WINDOWS\system32>ping 192.168.1.16

Pinging 192.168.1.16 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.16:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\WINDOWS\system32>

したがって、これは明らかに単なる ARPの問題ではありません。

これをPC 2の観点から見るとtcpdump、ping中に次のようになりました。

$ tcpdump -enr dump.cap
11:37:45.730405 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1317, length 40
11:37:45.730468 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
11:37:45.764667 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
11:37:45.764678 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1317, length 40

who-has手作業でレイアウトしたICMPエコーリクエストの前にはありません...しかし、PC 2は、1c:3e:84:c8:0c:08ARPクエリの成功後にエコー応答で明確に応答します-良いことですが-PC 1はそれを受信しないと主張しています。

さらに、pingの後、PC 2のARPテーブルにPC 1のアドレスがあります（以前に削除しました）。

$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
...
192.168.1.74             ether   1c:3e:84:c8:0c:08   C                     wlp3s0
...

PC 1とtcpdumpPC 2 でWiresharkでpingを繰り返すと、次のことがわかります（ダンプについては以下を参照）。

  • PC 1→PC 2からのトラフィックは問題ないようです
    • ソースのMAC書き換えはありません
  • PC 2→PC 1からのトラフィックは、ブロードキャスト（ARP要求など）の場合にのみ受信されます
    • そこで元のMACいじるには、

PC 1

$ tcpdump -enr pc1_dump4.cap
reading from file pc1_dump4.cap, link-type EN10MB (Ethernet)
12:17:59.525610 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40
12:17:59.641049 02:0f:b5:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
12:17:59.641080 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
12:18:04.345340 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40
12:18:09.346886 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40
12:18:14.347539 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40

PC 2

$ tcpdump -enr pc2_dump4.cap
reading from file dump4.cap, link-type EN10MB (Ethernet)
12:18:02.206931 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40
12:18:02.206995 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
12:18:02.289242 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
12:18:02.289254 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1330, length 40
12:18:07.122444 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40
12:18:07.122484 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1331, length 40
12:18:12.037691 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40
12:18:12.037729 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1332, length 40
12:18:17.170982 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40
12:18:17.171025 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1333, length 40

方向を逆にすると（PC 2はエコー要求をPC 1に送信します）、PC 1は要求を認識しません。

Windowsファイアウォールを無効にしても効果はありません。

最後の手段として、イーサネットでPC 1をルーターに接続することで問題が解決します...しかし、これは現在のところ許容できる解決策ではありません。

誰でも助けることができますか？

networking  wireless-networking  ping  arp 
— アティ
ソース
フォローアップとして、これはもはや問題ではないように見えます...物事は正常に動作しているように見えます（MAC変更を除いて）。
— Attie
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.