arp -d 192.168.1.1을 수행할 때까지 무선이 실패합니다.

arp -d 192.168.1.1을 수행할 때까지 무선이 실패합니다.

30분 이상 연결한 후 몇 분 사이에 무선 연결이 실패합니다.

증상:

  • 새 페이지가 열리지 않음
  • 다운로드가 이미 진행 중입니다. 계속
  • 핑 8.8.8.8이 작동하지 않습니다

"수정"은 쉽습니다(임의의 시간 동안 지속됨).

$ sudo arp -d 192.168.1.1

이 솔루션은 내가 확인한 결과 ARP 포이즌이 아니기 때문에 의미가 없습니다.

왜 이런 일이 발생하는지에 대한 아이디어가 있습니까?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=53.4 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.425/54.358/55.282/0.923 ms

무선 라우터: ZonHub 1.0(ISP에서 제공하는 맞춤형 Jungo의 OpenRG가 포함된 Hitron BVW3653 보드)



5월 1일 17:12 UTC 수정:

$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=79.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 53.544/62.396/79.815/12.317 ms
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0

내가 말했듯이 ARP 독이 아닙니다.

참고 1:다른 모든 것은 ISP에 의해 잠겨 있으므로 내 라우터에서만 웹페이지에 액세스할 수 있습니다.

답변1

이 답변은 모두 추측일 것입니다. 이것이 실제로 원인인지는 알 수 없지만...

ARP 테이블에서 라우터를 삭제하면 컴퓨터는 다음에 패킷을 라우터로 보내려고 할 때 강제로 ARP 패킷을 보내게 됩니다. 나는 이 ARP 패킷이 라우터의 ARP 테이블에서 손상된 모든 것을 수정한다고 추측할 수 있습니다. 왜냐하면 게시한 예에서 컴퓨터의 ARP 테이블은 괜찮은 것 같기 때문입니다("수정" 전후는 동일함).

라우터의 ARP 테이블을 볼 수 있다면 컴퓨터의 MAC 주소 대신 "(불완전)"이 표시될 것이라고 추측합니다(예를 들어 존재하지 않는 LAN 주소에 ping을 실행해 보세요). ARP 항목이 만료되고 ARP 패킷을 브로드캐스트하며 해당 브로드캐스트 패킷이 컴퓨터에 도달하지 않은 경우(또는 응답 패킷이 라우터에 도달하지 않은 경우) 해당 상태가 됩니다. ARP 패킷이 항목을 완료하고 IPv4 패킷을 컴퓨터로 다시 보낼 수 있습니다.

자, 왜 그런 일이 일어날까요? 두 가지 가능한 원인을 생각해 볼 수 있습니다. 라우터나 컴퓨터의 방화벽이 잘못 구성되었거나(제 생각에는 그럴 가능성이 낮음), 무선 라우터의 브로드캐스트에 문제가 있습니다.

802.11 표준의 브로드캐스트 패킷은 다소 문제가 있습니다. 모든 관련 스테이션으로 연결되므로:

  • 승인되지 않으므로 AP는 수신 여부를 알 수 없습니다. 이는 잘못 배치된 정전기의 단일 버스트가 브로드캐스트 패킷을 죽일 수 있음을 의미합니다.
  • 모든 방송국이 들을 수 있는 속도로 전송되어야 합니다. AP는 속도 제어 알고리즘에서 찾은 최상의 속도를 사용할 수 없습니다. 이는 일반적으로 BSS의 기본 속도보다 훨씬 낮은 속도를 의미합니다. 이는 더 많은 방송 시간을 사용하지만 이전 문제를 해결하는 데 도움이 됩니다(낮은 비율은 일반적으로 다소 더 강력합니다).
  • 동일한 패킷은 연결된 모든 스테이션에서 디코딩할 수 있어야 하므로 스테이션의 개별 키로 암호화할 수 없습니다. 대신 모든 관련 스테이션이 알고 있는 별도의 그룹 키로 암호화되어야 합니다. 이 그룹 키는 주기적으로 순환됩니다. 그렇지 않으면 네트워크를 떠난 스테이션이 여전히 브로드캐스트 패킷을 디코딩할 수 있습니다.

나는 개인적으로 이 마지막 요점과 관련하여 알 수 없는 실패를 경험한 것 같습니다. 한 번 구성한 액세스 포인트는 그룹 키 간격이 비활성화된 상태로 제공되었습니다. "이건 멍청한 짓이야"라고 생각하고 "왜 그 보안 기능을 비활성화하겠는가?"라고 생각하고 1시간으로 설정했습니다. 올바른 쪽에서 핑을 하여 해결할 수 있는 간헐적인 무선 연결 문제를 해결한 후(유선 쪽인지 무선 쪽인지 더 이상 기억나지 않습니다. 방화벽에 SSH 액세스가 있었고 ARP였던 것으로 기억합니다) 문제), 나는 통찰력을 갖고 "아, 그것이 기본적으로 비활성화된 이유입니다. 아마도 해당 액세스 포인트 펌웨어에 버그가 있어서 마지막 수정으로 0으로 설정했습니다"라고 생각했습니다. 기본값이며 문제가 사라졌습니다.

그것이 당신의 문제인지는 모르겠습니다. 제조업체가 완전히 다르기 때문에 아마도 그런 난해한 설정을 건드린 적이 없을 것입니다.

다음으로 시도해 볼 수 있는 일은 문제가 발생할 때 스니퍼를 실행하여 어떤 패킷이 교환되고 있는지 확인하는 것입니다. 두 번째 컴퓨터가 있는 경우 라우터의 이더넷 LAN 포트에 연결하고 동시에 스니퍼를 실행할 수 있습니다(ARP 브로드캐스트가 LAN에서는 표시되지만 무선에서는 표시되지 않는다는 내 가설이 장점이 있는지 확인하기 위해). ).

그리고 내 가설이 사실이라면 다운로드가 어떻게 계속 될지 전혀 모르겠습니다. 아마도 TCP 연결 상태에서 MAC 주소를 캐시하는 것일까요?

관련 정보