UniFi - UAP에서의 간헐적인 연결 이슈 디버깅하기¶

download at 2017-10-11T03:30:58Z origin

Overview

이 문서는 UAP에서 간헐적인 연결 이슈가 발생할 때 이를 해결하기 위한 몇가지 팁과 아이디어에 대하여 서술합니다. 종종 랩탑이나 모바일 폰으로 최대의 신호를 감지함에도 페이지가 로드되지 않거나 로딩중으로 나오지만, 결과가 없는 경우가 있을 수 있습니다. 다른 증상도 이 해결책이 도움이 될 수 있습니다.

Table of Contents

간헐적인 연결 증상
유선인가 무선인가?
환경설정을 점검해보자
AP 근접성
네트워크 루프
링크 예산
기능 비활성화
DHCP 환경설정
DTIM 주기 수정
와이어샤크 - 패킷 캡쳐
네트워크를 통한 패킷 트레이스
AP가 재부팅중인가?
하드웨어 점검
커뮤니티에 문의하기
관련 문서

간헐적인 연결 증상

맨위로 가기

가장 일반적인 간헐적인 연결 증상은 랩탑이나 모바일 폰에서 최대의 WiFi 신호를 확인할 수 있지만, 네트워크 서비스/브라우저를 사용할 때에는 사이트 혹은 페이지가 로딩되지 않는 이슈입니다. 브라우저는 종종 인터넷 연결이 없다고 표시할 뿐만아니라, 로딩 페이지를 영원히 로딩할수도 있습니다. 종종 WiFi 상태에 연결 불가능 표시가 출력되기도 하지만, 클라이언트 장비에서는 자동 할당된 IP (169.254.x.x 류의 IP)가 LAN으로 할당될 수 있습니다.

이러한 이슈의 많은 경우에는 최신 UAP 펌웨어에서 해결할 수 있습니다. 그러므로 최신 펌웨어 릴리즈를 장비에 설치하였는지 확인하십시오.

이 문서는 이러한 타입의 이슈를 해결하고 원활한 인터넷/네트워크 경험을 제공하기 위해 몇가지를 제한하고자 합니다.

유선인가 무선인가?

맨위로 가기

가장 먼저 문제가 유선 / 무선 인프라 네트워크에서 결정하는것이 가장 중요합니다.

랩탑의 2개의 터미널에서 지속적으로 구글의 퍼블릭 DNS (8.8.8.8)와 라우터로 동시에 핑을 시도하십시오. 양쪽 IP에서 패킷 손실이 발생한다면, 무선 이슈일 가능성이 높습니다. 8.8.8.8에서만 패킷 손실이 일어난다면, 유선/인터넷 이슈일 가능성이 높습니다.

이 문서는 무선 이슈만 다룹니다.

많은 랩탑이 WiFi 절전 모드가 활성화 되어 있다면, 랩탑이 충전 유무와 상관 없이 1.25초 정도 늦은 핑의 응답을 받게 될 것입니다. 특히 랩탑이 네트워크에서 아무런 작업을 하고 있지 않을지라도 말입니다. 이 모드는 랩탑 제공자가 전원을 절약하기 위해 고안하였습니다. 이 문서에서는 패킷 손실을 다루며, 패킷 지연은 다루지 않습니다.

환경설정을 점검해보자

맨위로 가기

다음 AP 네트워크 환경설정은 최소 3개의 에러가 포함되어 있습니다. 해당 에러를 포착할 수 있습니까?

서브넷 마스크가 게이트웨이에 경로를 제공하기에는 너무 좁습니다.
같은 서브넷에 있는 게이트웨이 자체가 고정 IP가 아닙니다.
선호하는 DNS가 설정되어 있지 않습니다.

잘못된 환경설정은 UPA 업그레이드, NTP 싱크 실패 등을 불러옵니다. 많은 다른 간헐적인 이슈도 포착하기 어렵게 됩니다.

최상의 사용자 경험을 위해서는 모든 UAP가 네트워크에서 완벽한 권리를 갖는 것이 중요합니다. 이 권리에는 DNS 접근 권한과 인터넷 라우터 유용성도 포함합니다.

AP 근접성

맨위로 가기

UAP를 클라이언트와 조금 더 가까이 위치시켜 보십시오. 문제가 사라지는지 확인해봅니다. 문제가 해결되었다면, UAP의 배포 위치를 조금 다른 곳으로 배치하는 것을 고려해 보십시오.

네트워크 루프

맨위로 가기

네트워크 루프는 tcpdump를 영향을 받는 UAP 혹은 UniFi 스위치에서 수행함으로써 쉽게 포착할 수 있습니다. 혹은 와이어샤크를 이용해도 확인할 수 있습니다 SSH로 영향을 받는 UAP에 접근하여 다음 명령어를 수행해봅니다:

ssh admin@192.168.1.X (UAP’s IP address)
tcpdump -i br0 -n -v -s 0 -w /tmp/capture.pcap

이후 pcap 파일의 결과를 랩탑에서 와이어샤크로 확인합니다.

scp admin@192.168.1.X:/tmp/capture.pcap /tmp

이 값은 capture.pcap 파일을 /tmp로 복사합니다. 또한 winscp로 같은 역할을 수행할 수 있습니다.

이제 와이어샤크에서 해당 파일을 열어봅니다.

어디선가 네트워크 루프가 발생하였다면, 많은량의 멀티캐스트 혹은 브로드캐스트 트래픽이 관찰되어야 합니다. 일반적인 네트워크에서는 100kbps 이하의 멀티/브로드캐스트 트래픽이 관찰되어야 합니다. 즉 초당 수십개 정도만 관찰 되어야합니다. 인프라 장비를 멀티캐스트/브래드캐스트 패킷이 적절한 숫자로 떨어질 때 까지 연결을 해지하십시오.

링크 예산

맨위로 가기

UniFi AP의 높은 전송 출력 (TX power)는 단일 AP 설치시에 훌륭하지만, 엔터프라이즈/다중 AP 배포에서는 문제가 발생할 우려가 있습니다. 높은 TX power는 느린 TX 비율을 확장할 것이며, 낮은 TX power가 높은 전송률을 보이는 것이 일반적인 모든 AP 장비와 대조적으로 나타나게 됩니다. 이는 다중 AP 배포상황에서 대부분의 전송시간을 차지하며, 전체적인 네트워크의 속도 저하와 잠재적으로 패킷 손실을 불러옵니다.

높은 전송 출력은 또한 모바일 클라이언트와 UAP 사이의 WiFi 링크 예산의 불균형을 초래합니다. 이는 대부분의 모바일 클라이언트가 TX power를 14~18 dBm (그리고 작은 안테나 등)을 갖기 때문입니다. 모바일 클라이언트는 지속적으로 AP와 강한 신호로 연결이 되어야 합니다. (그리고 최대 상태의 WiFi 상태를 보여주어야 하죠) 최대 신호는 모바일 클라이언트에서 AP로의 신호가 충분히 가능하지 않더라도 그렇게 보여야합니다.

UAP에서 TX power를 18 dBm으로 낮추십시오. 그렇지 않으면 더 많은 균형 링크 예산을 대부분의 장비와 배포 환경에 생성해야합니다. 이 과정은 컨트롤러 UI에서 쉽게 수행할 수 있습니다.

기능 비활성화

맨위로 가기

밴드 스티어링, 최소 RSSI, 연결 모니터등과 같은 기능은 잘못 설정되거나 충분치 않은 수의 AP로 구현하는 경우에는 역효과를 불러일으킬 수 있습니다. 이러한 기능이 병목으로 지목되었을 때 비활성화 하는것은 추가적인 작업 없이도 기본 기능이 문제가 없다라는 가정 하에 훌륭한 선택이 될 수 있습니다. 또한 새로운 기능 (예를 들면 ATF, 전송시간 공평성)을 비활성화 하여 기본 기능에 부담을 최소화 하도록 할 수 있습니다.

DHCP 환경설정

맨위로 가기

일부 오래된/잘못 설정된 라우터와 DHCP 서버는 DHCP 제안/응답 매시지를 브로드캐스트 패킷으로 전송합니다. 이 메시지는 대부분 버려지게 됩니다. 이는 느린 전송속도와 간헐적인 연결 이슈를 발생시킵니다. DHCP 제안과 응답 메시지를 브로드캐스트가 아닌 유니캐스트 패킷(클라이언트에서의 탐색 패킷은 여전히 브로드캐스트입니다)으로 전송하도록 하십시오.

DTIM 주기 수정

맨위로 가기

기본 1 DTIM 주기는 호환성과 기존의 이유로 사용되어 왔습니다. 그렇지만, 근래의 많은 (iOS와 안드로이드 폰을 포함한) 장비는 더 낫게 구동하며, WiFi 배터리 소비를 66%정도 절약하여 수행할 수 있습니다. 주기가 3으로 변경되더라도 말이죠. 거의 모든 현대의 기기는 DTIM 주기를 3으로 사용하는 것을 권장합니다.

와이어샤크 - 패킷 캡쳐

맨위로 가기

대부분의 플랫폼의 와이어샤크는 www.wireshark.org 에서 다운로드 받을 수 있습니다. 최신 (2013+) 맥북은 1) 모니터 모드를 위한 모든 드라이버 지원과 2) 3 NSS 트래픽을 감청할 수 있는 프리미엄 3x3 라디오를 지원합니다. 리눅스는 일부 랩탑에서 사용할 수 있지만, 대부분의 랩탑은 2x2 라디오를 지원하므로 기능이 많이 유용하지는 않습니다.

와이어샤크를 다운로드 받고 설치합니다.
와이어샤크 실행
최상단의 기어 아이콘 클릭
en0 인터페이스에 모니터 모드가 활성화 되었는지 확인
Close를 클릭하고, 와이어샤크 재실행
en0 캡쳐 시작, 이제 beacon, control, management frames 가 해당 데이터 프레임에서 확인할 수 있어야합니다. Note: 작성하는 시간에 와이어샤크의 모니터 모드에서 패킷을 캡쳐할 때 처음에는 실패가 발생하는 버그의 존재를 확인하였습니다.

네트워크를 통한 패킷 트레이스

맨위로 가기

일부의 경우, 멀티캐스트/브로드캐스트 패킷은 성공으로 적용 할 수 있는 반면에 유니캐스트는 그러지 않을 수 있습니다. 그러므로 어떤 타입의 패킷 이 얼마나 멀리 네트워크상에서 퍼질 수 있는지 이해하는 것은 매우 중요합니다.

무선 클라이언트의 "VAP" 인터페이스를 결정하여 연결해야합니다. ssh로 문제가 있는 AP에 연결하여 다음 명령어를 수행합니다:

iwconfig

위의 예제에서, ath6가 ubnt-ut-AR-LR네트워크 5GHz 대역의 VAP임을 알 수 있습니다.

가장 쉬운 방법은 핑 패킷을 전송하는 것입니다.

브로드캐스트 패킷이 UAP로 전송되는 것을 확인할 수 있다면, tcpdump를 실행하여 athX 인터페이스를 확인하비다. (SSH로 UAP에 접속합니다):

tcpdump -i athX -n -v -s 0 -w /tmp/broadcast.pcap

이후 일부 브로드캐스트 패킷을 핑으로 랩탑에서 전송합니다:

ping 192.168.1.255

캡쳐를 중단하고, /tmp/unicast.pcap 로 캡쳐를 시작합니다. (UAP에 SSH로 실행)

tcpdump -i athX -n -v -s 0 -w /tmp/unicast.pcap

다음은 유니캐스트 패킷을 라우터에 전송을 시도합니다. (랩탑에서 수행)

ping 192.168.1.1 (replace with your router’s IP)

브로드캐스트 패킷을 전송, 수신이 되지 않는다면, 유니캐스트 패킷이 원활하지 않은 것입니다. (ARP 엔트리가 OS에 없는 것입니다.) 혹은 고정 ARP 엔트리가 랩탑에 필요할 수도 있습니다. (랩탑에서 수행)

sudo arp -s 192.168.1.1 00:00:00:00:00:01 ifscope en0 (Mac OS X)
arp -s 192.168.1.1 00-00-00-00-00-01 (윈도우 커맨드라인 관리자권한)

핑을 다시 수행해봅니다. 00:00:00:00:00:01로 유니캐스트 패킷이 UAP의 athX 인터페이스로 동작하는지 확인합니다.

클라이언트에서 UAP로의 패킷 손실이 발생하는지 확인한 다음에는 UAP에서 클라이언트로의 패킷 손실이 발생하는지 확인할 차례입니다. 먼저, 와이어샤크나 tcpdump를 랩탑에서 수행하여 패킷을 제대로 받을 수 있는지 확인합니다. 이후 브로드 캐스트 패킷을 UAP에서 네트워크로 전송합니다. (UAP에서 SSH로 수행합니다):

ping 192.168.1.255

와이어샤크/tcpdump 결과를 캡쳐하고, 랩탑으로 핑을 수행합니다 (UAP에서 SSH로 수행):

ping 192.168.1.X

작성하는 시점에서 UAP는 고정 ARP 엔트리로 설정하지 않았습니다. 그러므로 유니캐스트 트래픽은 UAP에서 생성되지 않고, 유선 데스크탑/랩탑에서 고정 ARP 엔트리가 설정된 패킷을 생성할 수 있습니다. 그후에는 다른 장비에서 패킷을 전송할 수 있습니다.

캡쳐 결과를 커뮤니티에 공유하거나 UBNT 관리자에게 패키 손실이 발생하는 원인에 대하여 진단을 요청할 수 있습니다.

마지막으로, 브릿지가 올바르게 구성되어있는지 확인해보십시오 (UAP에서 SSH로 수행):

brctl show

결과는 다음과 같이 출력되어야 합니다:

Bridge Name

Bridge ID

STP Enabled

Interfaces

br0

ffff.44d9e7f9876a

no

ath0

ath1

ath2

ath3

ath4

ath5

ath6

ath7

eth0

AP가 재부팅중인가?

맨위로 가기

AP의 부팅 시간을 점검하여 리부팅이 수행중인지 아닌지 확인하십시오. 부팅시간이 지속적으로 리셋되면, 네트워크 중단시간도 이에 일치해야합니다. 그렇게 한다면, 발견되지 않은 버그를 발견할 수도 있습니다. 그리고 이제 기쁘게 다시 버그를 재현할 수 있게 됩니다. 해당 버그를 우리 Community 알려주십시오.

하드웨어 점검

맨위로 가기

하드웨어가 우리 공장에서 여러분의 책상까지 많은 손을 타다보면 손상이 갈 우려가 있습니다. 중요한 패킷 손실이 해결되지 않는다면, 이 절을 계속해서 읽어보십시오.

2 GHz와 5GHz 무선이 서로 다른 SSID로 설정하는 것이 가장 좋으며, 모든 서로 다른 UAP에서 서로 다른 SSID를 설정하는 것이 더 좋습니다. 예를 들면, 네트워크 이름을 "HomeNetWork"에서 2 GHz는 "HomeNetWork-test2"로, 5 GHz는 "HomeNetWork-test5"로 설정하여 서로 충돌하지 않도록 하는 것입니다. 1개 이상의 무선 스테이션 SSID를 보유한다면 1개의 SSID 를 무선 하나당 갖도록 하여, 밴드당 하나 의 SSID를 갖도록 하는 것이 좋습니다.

SSID를 위와 같은 방식으로 수정한 이후에는, SSH로 접속하여 다음 명령어를 UAP에서 실행합니다:

iwpriv wifi0 get_txchainmask

이 과정은 radio 0 에서 몇개의 가능한 체인 수를 제공합니다. 이 값은 마스크로서, 3은 2개의 체인을, 5는 2개의 체인, 7은 3개의 체인, 15는 4개의 체인 등입니다. 다음 명령어를 UAP의 두번째 무선 스테이션에서 수행합니다. (UAP는 듀얼밴드입니다):

iwpriv wifi1 get_txchainmask

이제 UAP의 각 체인을 테스트 합니다. 다음은 체인 0을 테스트 하는 코드입니다:

cm=1; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd

"WiFi Analyzer" 혹은 다른 앱을 사용하여 체인 0의 2 GHz, 5GHz 두가지 모두의 UAP의 신호 세기를 확인하십시오. UAP에서 10 feet 안에서 있어야 하며, 신호 세기가 -60 dBm보다 약하면, 체인에 문제가 있는 것입니다. 다른 체인에서 아래를 수행합니다:

cm=2; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd

체인 1에서 신호 세기를 다음과 같이 확인합니다:

cm=4; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd

cm=1, 2, 4가 각 체인 0, 1, 2를 의미한다는 것을 기억하고, UAP가 체인 2가 없다면 체인에서 어떤 신호도 확인할 수 없을 것입니다.

다음으로는 UAP를 재부팅하여 체인을 원상태로 복원합니다. 신뢰할 수 있는 랩탑으로 UAP에 10 feet 이내에서 연결한 다음 iperf3을 유선 서버에서 실행합니다:

iperf3 -s

이후 WiFi가 연결된 랩탑/모바일 기기에서 iperf3를 수행합니다:

iperf3 -u -c SERVER_IP -b 50M -R

반대 방향에서 다시 수행합니다

iperf3 -u -c SERVER_IP -b 50M

고장난 하드웨어는 단방향에서 더 적은 출력량을 일반적으로 확인할 수 있습니다. 이 경우에 속한다면 포럼 토픽에서 다음 단계를 수행하기 위해서 @mention으로 UBNT 직원을 호출해주십시오.

커뮤니티에 질문하기

맨위로 가기

모든 방법이 실패한다면, 증상과 환경설정을 커뮤니티와 UBNT 엔지니어에 문의해주십시오. 이 가이드에서 관련된 단계를 수행하시고, 또한 밴드-스티어링, minRSSI, ATF, VLAN 등의 설정등을 포함하십시오. 문제가 해결되었다면 해당 토픽이 해결되었다고 표시하는 것을 잊지마십시오!