라즈베리 파이는 Wi-Fi 브리지를 통해 라우터나 인터넷 주소를 핑할 수 없습니다.

라즈베리 파이는 Wi-Fi 브리지를 통해 라우터나 인터넷 주소를 핑할 수 없습니다.

나는 최근에 "Atheros" 버전을 사용하여 일종의 리피터 브리지로 DD-WRT를 실행하는 WNR2000v3 라우터를 설정했습니다.이 튜토리얼(이것을 '라우터 2'라고 함) 이는 Medialink Wireless-N 라우터(이것을 '라우터 1'이라고 함)를 반복합니다. 이것은 Wi-Fi를 통해 그리고 이더넷을 통해 직접 연결된 경우 내 안드로이드 휴대폰과 Windows 컴퓨터에서 완벽하게 작동하지만 Raspbian(wheezy) 또는 Raspbmc를 실행할 때 Raspberry Pi를 연결하면 로컬 네트워크 외부에서 연결할 수 없습니다.

라즈베리 파이는 직접 연결된 '라우터 2'를 포함하여 로컬 서브넷의 다른 장치에 핑을 보낼 수 있고 라우터 1에서 DHCP를 얻을 수 있지만 시도하면 라우터 1에 대해 ping을 실행하면 "Destination Host Unreachable" 메시지가 표시되고, google.com, superuser.com과 같은 인터넷에서 ping을 시도하면 마찬가지로 "Destination Host Unreachable" 메시지가 표시됩니다.

네트워크에 있는 다른 컴퓨터는 다음과 같습니다.

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.

다른 모든 것은 잘 작동하지만 두 개의 다른 이미지(Raspbmc 및 raspbian)와 두 개의 다른 라즈베리 파이를 사용하여 이 랩스베리 파이를 시도했지만 구성이 작동하지 않습니다. Raspbian 이미지는 라우터 1에 직접 연결되었을 때 작동하는 것으로 테스트되었습니다. 이 문제는 다음과 매우 유사해 보입니다.답이 없는 이 질문단, 그 경우에는 연결에 실패한 장치에 Wi-Fi를 사용하고 있었던 것으로 보이며 실제로는 간헐적으로 연결이 끊어지고 있었습니다. 또한 핑 응답은 장치가 아닌 라우터에서 나왔습니다. 이 문제의 원인은 무엇입니까?

편집하다:또한 두 개의 서로 다른 라즈베리 파이는 서로 다른 IP 주소를 가지고 있으며 그 중 하나는 IP-MAC에 바인딩되어 있으며 DHCP 테이블에서 본 IP 충돌은 없었지만 각각 동일한 문제가 있다는 점에 유의해야 합니다.

업데이트: 잠재적으로 흥미로운 점 하나를 확인했습니다. 즉, MAC 주소 복제가 꺼지면 리피터 브리지가 작동을 멈춘다는 것입니다. 라즈베리 파이에 ping을 보낼 수 있는 유일한 것은 라우터 2이고 연결이 없습니다(또는 라우터 1에 대한 액세스가 없습니다). ) Windows 시스템을 포함하여 라우터 2에만 연결된 모든 것에서. 그러나 복제되는 mac 주소는 어쨌든 ("상태" 페이지에 따라) 라우터 2의 인터페이스에서 실제로 사용되는 것과 동일한 mac 주소입니다. 라우터 1과 라우터 2의 전원을 두 번 껐다 켜봤는데 아무런 차이가 없습니다. MAC 주소 복제가 여기서 왜 관련되는지 이해가 되지 않습니다. MAC 주소 복제가 꺼진 상태에서 라우터 자체에 SSH로 연결하면 라우터는 Raspberry Pi를 핑할 수 있지만 라우터 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이 아닌 라우터 2로 변경하는 것입니다.

또 다른 방법은 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보다 더 잘 작동합니다. 물론 이러한 잘못된 인상은 연결 속도를 측정할 때까지 지속됩니다.

답변4

비슷한 문제가 얼마 전에 발생했습니다. 내 솔루션 /etc/resolv.confnameserver 8.8.4.4. /etc/init.d/networking restart그것은 나를 위해 작동합니다.

관련 정보