반응형

며칠 전부터 휴가 기간이 되면서 잠시 고향 집에 방문하게 되었다.

오랜만에 뵙는 반가운 가족들, 맛있는 고향의 음식들과 함께 나의 관심을 끄는 작은 문제점 하나가 있었으니, 바로 내가 오래 전에(거의 8년쯤 전) 설치해 둔 와이파이 공유기가 전원 계통이 고장나서 더이상 켜지지 않는 것이었다. 하긴 IEEE 802.11n 표준도 구현되어 있지 않던 값싼 구형의 액세스 포인트를 지금까지 단 한 번도 전원을 끄지 않고 써 왔으니 하드웨어에 문제가 생길 만도 했을 것이다.


집에서는 통신사에 요청해서 무선랜 서비스를 새로 신청해 둔 상태라고 했지만, 내가 방문했던 때는 휴일이라서 당장 와이파이를 쓸 수는 없는 상황이었다. 마침 나는 랩탑을 갖고 있었고, 랩탑에 내장된 와이파이 인터페이스를 사용해서 내가 집에 있는 동안만 임시로 와이파이 AP를 만들면 되겠다고 생각했다.


내 랩탑에는 윈도우 10과 우분투 14.04가 멀티부팅으로 설치되어 있었고, 윈도우에서는 이미 잘 알려진 Connectify라는 어플리케이션을 설치해서 쓸 수는 있었지만 무료 버전의 경우 설정에 제한이 많고 설치되는 윈도우 환경을 더럽히는(?) 듯한 느낌이 들어서 우분투에서 쉘 스크립트로 직접 AP를 만들기로 했다.


AP를 설정하는 방법은 지금 연구실에서 실험으로 쓰고 있는 라즈베리파이 기반의 무선 메쉬 네트워크 환경에서 AP 생성하는 방법만 가져오면 되었기에 금새 완료할 수 있었다. 랩탑에 랜선을 꽂고, 와이파이 인터페이스, hostapd, isc-dhcp-server, iptables를 차례대로 설정해 주었다.


금새 스마트폰에 나타난 새로운 와이파이 액세스 포인트에 동생은 신기해하면서 바로 내가 생성한 와이파이에 접속해서 스마트폰을 쓰기 시작했고, 나는 평소에 연구하던 것이 이럴 때 도움이 될 수 있다는 것이 뿌듯했다.


하지만... 역시 임시로 만든 AP는 어디까지나 임시로밖에 쓸 수 없다는 현실을 체험하는 계기가 되었다. 내가 집에 갔던 첫째날과 다음날까지 내가 랩탑으로 생성한 와이파이 AP를 실제로 써 보면서, 물리적인 무선랜 공유기와의 성능 차이를 몸소 체험할 수 있었다. ㅜㅜ


가장 먼저는 이상하게 랩탑이 자꾸만 인터넷에 한동안 연결을 하지 못하는 문제로 인해서 스마트폰 입장에서는 와이파이에 접속한 상태는 변함이 없지만 갑자기 인터넷이 안 되는 현상이 간헐적으로 일어났다. 그런 문제가 생겼을 때 내가 바로 재부팅으로 해결하는 바람에 원인을 정확하게 파악하지는 못했지만, 재부팅하기 전에 도메인 네임 서버에 ping이 가지 않았던 현상을 통해서 도메인 네임 서버와의 연결이 간헐적으로 끊어졌던 것 같다.

두 번째로는 속도가 그다지 만족스럽지는 못했다. 내가 AP로 설정한 노트북인 삼성 뉴 시리즈9(NT900X3C-A64)이 비록 802.11n을 내장하고 있었고 안드로이드에서도 접속했을 때의 속도가 65Mbps였지만, 실제로는 그 속도가 나오지 않았다. ㅜㅜ 플레이스토어에서 각종 앱을 다운로드 받아서 설치한 적이 있었는데 그 때의 체감속도가 대략 16-24Mbps (1초에 약 2-3MB 정도를 다운로드 받았으므로 bps로 환산하면 대략 이 정도)였다. 동생도 와이파이를 쓰는 동안 좀 느리다고 얘기했던 것을 보면, 제대로 AP 역할을 수행하기 위해서는 HT를 비롯한 좀더 세부적인 설정이나 tweak 등을 해 줬어야 하는 것 같다. 하지만 나는 그렇게까지 자세한 설정을 고치지는 못했고, HT20, HT40 같은 것을 적용해 보려고 노력했지만 결국 실패로 돌아갔다.


결국 이틀간 쓰면서 이전에 고장나기 전까지 쓰던 802.11g보다 오히려 안정적이지 못하고 속도도 별 차이가 없거나 오히려 느리다는 결론을 내릴 수밖에 없었다.

집에 2박 3일 간 머무르는 중에 첫 이틀을 이렇게 내가 랩탑으로 와이파이를 만들어서 쓰고, 마지막 날 아침에는 통신사가 직접 자체 와이파이 공유기를 설치해 주었는데, 그 전용 장비의 체감 속도와 안전성은 확연히 달랐다.


비록 실제로 시중에서 쓰는 공유기들이 랩탑에 비하면 매우 느린 CPU와 아주 적은 양의 메모리를 갖고 있지만, 아무래도 AP 역할을 잘 할 수 있도록 외부로 노출된 안테나를 포함해서 최적으로 설계된 와이파이 네트워크 인터페이스와 그외 여러 측면에서 최적화된 라우터 전용 운영체제와 세부 소프트웨어 설정의 영향을 무시할 수 없는 것 같다. 

결론적으로, 와이파이가 아예 없는 것보다는 랩탑으로 설정한 AP라도 있는 것이 훨씬 나았지만, 전용 하드웨어가 제공하는 와이파이는 그 임시방편보다도 한층 더 좋을 수밖에 없었다. 혹시나 나중에 와이파이 말고도 또다른 연구하던 것을 현실에 써먹어야 할 때에는 꼭 실제 제품과의 차이가 클 수 있다는 것을 염두에 둬야겠다.


반응형
블로그 이미지

Bryan_

,
반응형

WLAN: TP LINK TL-WN722N (Atheros ath9k_htc)

OS: Raspbian Jessie



처음에는 IEEE 802.11(와이파이)로 애드혹 모드(ad-hoc mode)가 HT (High Throughput)를 지원하지 않을 거라 생각했는데, 지원하는 것 같고 설정방법도 존재하는 것을 확인했다. 다만 실제로 속도가 개선되지는 못했는데, 다른 부분에서 성능상의 bottleneck이 존재할 수도 있기 때문에 좀더 조사해 봐야 한다.


어쨌든 이 글에서는 애드혹 네트워크를 구성할 때 HT 모드를 명시적으로 지정하는 방법을 설명한다. 아쉽지만 흔히 쓰는 /etc/network/interfaces 파일에서 HT 모드를 적용하는 방법은 찾을 수 없었다.

그래서 iw를 써야 한다. 명령어가 없을 경우 apt-get install iw로 설치한다.


조사해 보니 아래와 같은 명령으로 애드혹 네트워크와 함께 설정할 수 있다. [1, 2, 3]


# iw dev [인터페이스_이름] ibss join [네트워크_이름] [채널_KHz단위] [HT_모드] [Cell_ID]

# ifconfig [인터페이스_이름] [원하는_IP_주소]


무선랜 인터페이스가 어떤 HT 모드를 지원하는지 확인하려면 iw list를 통해서 나오는 디바이스 정보를 확인한다. 디바이스 이름은 wlan 대신 phy0, phy1 등으로 표시된다. wlan 몇번이 phy 몇번인지 확인하려면 귀찮은 과정을 거쳐야 하지만, 보통 무선랜카드를 1개만 USB로 연결하면 iw list에서도 디바이스가 하나만 나오므로 확인이 어렵지 않을 것이다.


출력 결과에서 Capabilities 부분에 HT20, HT40 등의 단어가 나온다면 HT20, HT40을 지원한다는 의미이다. 어떤 rate를 지원하는지는 "HT TX/RX MCS rate indexes supported: 0-7" 이러한 문장의 끝에 적힌 숫자에서 확인할 수 있다. 그리고 "Device supports HT-IBSS." 라는 문장이 있으면 애드혹 모드에서도 HT가 될 것이다.


필자가 갖고 있는 TL-WN722N 무선랜카드는 HT20, HT40을 지원한다고 나와 있다. 

HT40은 HT40+, HT40- 두 가지가 있는데, 시도해 본 결과 HT40-일 때에만 에러 없이 설정이 되었다. 



<추가>

글을 처음 쓸 당시에는 몰랐는데, HT40은 기존의 20MHz 채널 2개를 합쳐서(aggregate) 40MHz짜리 채널을 만들기 때문에 기준 주파수에서 어느 쪽으로 추가 20MHz를 붙일지 결정하기 위해서 +, - 부호를 쓰는 것이었다. 즉, 기준 채널보다 큰 주파수에서 추가로 20MHz를 갖다붙이려면 HT40+를 쓰고, 기준 채널보다 작은 주파수에서 붙이려면 HT40-를 쓴다.


채널 11번(2462 MHz)에서 HT40+가 안됐던 이유는, 11번 채널이 와이파이가 접근 가능한 2.4GHz의 주파수 대역에서 가장 끝이기 때문이다. (물론 하드웨어에 따라서 12, 13번 채널을 허용하는 경우도 간혹 있지만, ath9k_htc는 11번까지만 쓰도록 한 것 같다.)

그래서 11번 채널에 HT40-를 적용하면 기존 20MHz (2452 ~ 2472)보다 작은 주파수에서 20MHz (2432 ~ 2452)를 가져오기 때문에, 총 40MHz 채널에 대한 중앙 주파수는 2452 MHz가 된다. $ iw [인터페이스_이름] info 명령을 쳐 보면, center1 항목에서 확인할 수 있다.


결론적으로, 채널 1번으로 설정하면 HT40+밖에 안되고, 채널 6번으로 설정하면 HT40+, HT40- 모두 설정 가능하다.



예를 들어, testRpiAdhoc 이라는 이름의 애드혹 네트워크에 무선채널 11번(2.462GHz)을 쓰고, 고정IP 주소를 192.168.3.4를 할당하는 경우, 아래와 같이 설정할 수 있다.


$ sudo iw dev wlan1 ibss join testRpiAdhoc 2462 HT40- F6:D0:8C:DD:C3:AB

$ sudo ifconfig wlan1 192.168.3.4


뒤에 Cell ID는 맥주소 형식으로 임의로 입력해도 되며, 단지 애드혹 네트워크에 참여하는 기기들이 모두 같은 값을 공유하면 되는 듯 하다. 




<참고자료>

[1] https://wireless.wiki.kernel.org/en/users/documentation/iw/replace-iwconfig#join_an_ibss_ad-hoc_network

[2] http://www.spinics.net/lists/linux-wireless/msg83366.html

[3] https://forum.openwrt.org/viewtopic.php?id=29876



반응형
블로그 이미지

Bryan_

,
반응형

테스트 대상 기기: 삼성 갤럭시 노트3 네오, LGU+ (SM-N750L)

Android 버전: 4.4.2


스마트폰을 통한 네트워크 실험을 하는 과정에서, 여러 차례 와이파이에 연결된 스마트폰에 ping을 날려야 하는 경우가 있었다. 화면이 꺼져 있더라도 옵션을 통해서 와이파이에 항상 연결되어 있게 할 수는 있는데, 유독 화면이 꺼져 있을 때에 ping 속도가 느린 것 같다는 느낌이 들어서 실제로 테스트를 해 보았다.

샘플 수가 20개라서 사실 많지는 않지만, 그래도 동일한 환경에서 주변에 다른 방해하는 기기가 거의 없는 새벽 시간대에 해 본 것이라서 어느 정도 의미는 있을 것으로 생각한다.


테스트 환경으로, 라즈베리파이 2B에 hostapd를 돌려서 가상 AP로 만들고, 스마트폰이 그 AP에 연결되도록 했다.

라즈베리파이는 Raspbian Jessie 운영체제에 Atheros ath9k-htc 기반의 USB 무선랜카드를 달고 있고, IEEE 802.11n 모드로 AP를 돌렸다.

테스트용 스마트폰 외에 무선으로 연결된 다른 연결된 기기는 없었다.


아래는 화면이 꺼져 있을 때, 의 ping 결과이다.

pi@raspberrypi ~/exp $ ping 10.0.5.10

PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.

64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=289 ms

64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=113 ms

64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=344 ms

64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=157 ms

64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=204 ms

64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=164 ms

64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=188 ms

64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=9.65 ms

64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=237 ms

64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=276 ms

64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=80.7 ms

64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=105 ms

64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=126 ms

64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=205 ms

64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=220 ms

64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=258 ms

64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=254 ms

64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=290 ms

64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=312 ms

64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=135 ms

^C

--- 10.0.5.10 ping statistics ---

20 packets transmitted, 20 received, 0% packet loss, time 19025ms

rtt min/avg/max/mdev = 9.658/198.845/344.289/84.791 ms



아래는 스마트폰 화면을 켜고, 바탕화면을 전환하거나 카카오톡 앱을 한번 켜 보는 등 화면을 켜져 있도록 유지했을 때의 ping 결과이다. 카카오톡을 켤 때 잠시 서버에 접속하는 경우를 제외하고는 스마트폰에서 별도로 트래픽을 발생시키지 않았다.


pi@raspberrypi ~/exp $ ping 10.0.5.10

PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.

64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=146 ms

64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=67.5 ms

64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=81.2 ms

64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=133 ms

64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=128 ms

64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=147 ms

64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=175 ms

64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=98.5 ms

64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=109 ms

64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=9.62 ms

64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=66.1 ms

64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=81.9 ms

64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=108 ms

64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=139 ms

64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=146 ms

64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=75.2 ms

64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=5.52 ms

64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=4.06 ms

64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=4.30 ms

64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=188 ms

64 bytes from 10.0.5.10: icmp_seq=21 ttl=64 time=78.3 ms

^C

--- 10.0.5.10 ping statistics ---

21 packets transmitted, 21 received, 0% packet loss, time 20028ms

rtt min/avg/max/mdev = 4.062/95.085/188.859/54.672 ms



최소값, 최대값, 평균 모두 차이가 남을 알 수 있다.

평균을 기준으로 대략 2배 가량 전송시간(round trip time)의 차이가 발생했다.

참고로 같은 증상이 삼성 갤럭시 넥서스(버전 4.1.1)에서도 나타났다.


무슨 연유로 어디에서 이러한 지연이 발생하는지는 정확하게 알 수 없다. 하지만 아마도 스마트폰에서 의도적으로 지연을 발생시켰을 것으로 예상되며, 그 이유는 여러가지가 있겠지만 에너지 절약 차원의 목표가 있을 것이라고 추측만 하고 있다.

네트워크 실험을 할 때에는 (물론 화면을 끄고서 실험할 일은 거의 없겠지만) 스마트폰 화면의 꺼짐 유무도 잘 확인하는 것이 좋겠다.



반응형
블로그 이미지

Bryan_

,
반응형


2013년부터 잘 써오던 넥서스7 1세대 WiFi 모델을 쓰다 보면, 가끔 전원이 안 켜질 때가 있다. 이유없이 방전이 되어 있고, 방전되고 나서 다시 켜려고 하면 충전중인 상태에서 아주 길게 누르고 있어야 켜진다. (20초 이상)


이번에도 쉽게 전원이 켜지지 않아서 왜 그런지 찾아보다가, 가끔 내장 배터리가 약간 분리되어 있을 수도 있다는 블로그 글을 발견했다.

(출처: http://badaro2001.tistory.com/289)


뒷판을 분리해 보니 배터리 연결선에 이상이 있지는 않았지만 여전히 켜지지 않아서 (아마도 완전 방전) 뒷판을 연 상태로 이리저리 만지다가 큰 실수를 저지르고 말았는데,


빨간 표시 안에 있는 와이파이 단자가,


이렇게......


똑 떨어지면서 망가져 버렸다. ㅠㅠ


그런데 야속하게도, 마침 전원은 다시 잘 켜진다. (나는 뒷판은 왜 연 것인가? ㅋㅋ)

일단 뒷판을 연 상태에서는 뒷판에 붙어 있는 와이파이 안테나에 접촉이 안되므로 와이파이 성능이 매우 떨어졌는데, 위와 같이 단자 하나가 부러진 상태로 다시 뒷판을 끼웠더니 생각보다 성능이 나쁜 부분이 느껴지지는 않았다.


아마 집안에 있는 와이파이 액세스 포인트(access point)에 연결을 해서 테스트했기 때문에 신호 세기가 충분해서 별 차이가 없었을 지도 모르겠다. 하지만 와이파이 신호 간섭이 심한 연구실에 들고 간다면 어떤 성능을 보여줄 지 모르겠다. ㅜㅜ


아무래도 뽐뿌에 올라온 어떤 사용자의 해결책처럼 (http://m.ppomppu.co.kr/new/bbs_view.php?id=androidtab&no=54349) 전선을 이용해서 납땜을 하는 방법으로 가야할 것 같다. 아니면 끊어진 단자 자체를 납땜으로 붙여서 연결해야 할 것 같다. 슬프네... ㅜㅜ



반응형
블로그 이미지

Bryan_

,
반응형

<테스트한 환경>

OS: Ubuntu 11.04 Desktop (32bit, kernel 2.6.38-8-generic)

네트워크 인터페이스: TP-LINK TL-WN722N (802.11b/g/n)



연구실험 목적으로 와이파이 무선 애드혹 네트워크를 구성해서 쓰면서 유난히 연결이 안되는 경우가 자주 있었는데, 경험을 바탕으로 몇 가지 원인을 나열해 보고자 한다.



(1) Ubuntu desktop의 Network Manager 서비스와 /etc/network/interfaces 파일 간의 설정 불일치


고정IP와 채널 설정 등 가장 확실하게 설정할 수 있는 방법은 우분투(Ubuntu)를 기준으로 /etc/network/interfaces 파일을 수정하는 것이다. 그런데 Ubuntu desktop에서 쓰는 서비스인 network-manager는 /etc/network/interfaces 파일을 참고하지 않고 별도로 설정을 보관한다. 즉, network manager에서 그래픽 유저 인터페이스(GUI)를 이용해서 설정을 변경하더라도 /etc/network/interfaces 파일에 반영되지는 않는다.

반대로 /etc/network/interfaces 파일을 수정하면 network-manager의 상태 메세지가 그 변경 내역을 반영하는 것 같지만, 별로 신뢰가 가지 않는다. 가끔 network-manager가 오작동을 하면서 시스템 전체가 다운되는(커널 패닉; kernel panic) 현상도 겪었다.


개인적으로는 network-manger 서비스를 삭제해 버리고, 오직 /etc/network/interfaces 파일을 통해서만 모든 네트워크 설정을 하는 것을 추천한다. 그래픽 인터페이스가 아니라서 직관적이지는 않겠지만, 이것이 오작동 없이 설정하는 가장 확실한 방법이다. 우분투에서 network-manger 서비스 삭제는 아래와 같이 할 수 있다.

$ sudo apt-get remove network-manager


만약 network-manager를 삭제하는 대신 일시적으로 서비스를 중단하고 싶다면 service disable 명령어를 이용한다.

$ sudo service network-manager disable




(2) 다른 유선/무선 네트워크 설정과 같은 IP주소 대역을 쓰는 경우


별 생각 없이 애드혹 네트워크를 구성하면서 고정IP 주소를 192.168.0.X 또는 192.168.1.X를 쓰는 경우가 많이 있다. 하지만 대부분의 경우 공유기를 통해 연결하는 유선랜 연결에서 할당받는 유동 IP 주소가 대부분 192.168.0.X 또는 192.168.1.X라는 사실을 염두에 둬야 한다.

필자의 경우 무선 와이파이는 애드혹 네트워크로 설정하고 유선랜은 원격 ssh 접속 및 디버그 용도로 쓰려고 했는데, 공교롭게도 유선과 무선이 같은 대역의 IP 주소를 쓰는 바람에 기대하던 대로 연결되지 않는 현상을 겪었다.

애드혹 네트워크를 고정IP로 쓰는 경우, (게다가 애드혹 모드에서 고정 IP를 쓰지 않으면 제대로 연결되지도 않음) 다른 네트워크과 서브넷(subnet) 주소가 겹치지 않도록 주의하자. (예를 들어, 192.168.3.X 대역을 쓰는 식으로 주소를 확실하게 구분할 것)




(3) Cell 정보가 잘못되어서 생기는 문제


애드혹 네트워크의 경우 고정된 게이트웨이(공유기의 역할)가 따로 있지 않지만, 설정상으로는 가상의 게이트웨이처럼 Cell 정보를 갖고 있다. 콘솔에서 iwconfig를 입력하면 맥 주소 형태로 된 cell 정보를 확인할 수 있다. 같은 애드혹 네트워크에 있는 모든 노드가 같은 cell 정보를 공유한다.


(iwconfig 명령을 통해서 확인할 수 있는 애드혹 네트워크의 각종 정보. 밑출 친 부분이 Cell 정보이다.
Cell 값은 특정 노드의 맥주소는 아니고, 재구성할 때마다 임의의 값을 할당받는 것으로 보인다.)


아직 정확한 원인은 모르지만, 설정상 전혀 이상이 없는데도 갑자기 애드혹 네트워크 상의 노드들끼리 전혀 통신을 못하는 경우가 있다. 그래서 각 노드를 하나씩 네트워크 재설정도 해 보고,  (sudo /etc/init.d/networking restart) 각 노드를 재부팅도 해 봤으며, USB 무선랜 카드를 뽑았다가 다시 연결하기도 했지만 여전히 되지 않았다.


확인해본 결과 노드를 하나씩 재설정/재부팅해서는 안 된다. 아마 Cell 정보에 문제가 있었던 것 같은데, 장비를 하나씩 재시작하면 네트워크가 켜져 있는 다른 노드가 계속 기존의 설정을 유지하고 있기 때문에, 그 노드로부터 잘못된 정보를 받아 와서 다시 공유하게 된다. 그러므로 확실하게 하려면, 모든 노드가 다같이 전원을 껐다가 켜야 한다. (애드혹 네트워크를 완전히 없앴다가 다시 만들자는 얘기) 이렇게 하면 iwconfig를 통해서 Cell 정보가 변경된 것을 확인할 수 있으며, 다시 노드들끼리 정상적으로 통신이 된다.




(4) 신호 세기와 물리적인 공간 특성으로 인한 문제


필자의 경우 넓은 지역에 먼 거리를 두고 노드를 배치할 필요가 없어서 이 문제가 치명적이지 않았다. 하지만 건물 안에서 멀티홉(multi-hop) 네트워크를 구성하기 위해 복도와 방을 이용해서 배치해본 결과, 벽과 코너의 구조로 인해서 신호를 받지 못하거나 신호가 미약한 상황을 만들어낼 수는 있었다. (사족: 하지만 결국은 실내 공간에서 물리적인 배치만 가지고 멀티홉 네트워크 만들기는 실패했다. 왜냐하면 어떻게든 미약한 신호가 닿을 경우 한번에 연결하려고 하지 중간 노드를 통해서 가려는 시도를 안하기 때문이다. ㅠㅠ 결국 라우팅 프로토콜에 약간의 예외처리를 해서 소프트웨어적으로 멀티홉을 구성해야 했다.)


필요에 따라 신호 세기를 조정해서 전송 범위(transmission range)를 바꿀 수 있다. 신호 세기가 세면 당연히 전송 범위가 늘어난다. 신호 세기는 아래와 같이 조정할 수 있다.

$ sudo iwconfig [네트워크_인터페이스_번호] txpower [신호세기]


신호 세기의 단위는 dBm이며, 0~20 사이의 값만 허용된다.


(iwconfig를 이용해서 신호 세기를 4dBm으로 설정한 경우)


또한 무선랜에서는 data rate가 낮을 수록 또한 전송 거리가 늘어나기도 한다. 그러나 아쉽게도 애드혹 모드에서는 data rate 설정을 변경할 수 없으니 참고하자.







반응형
블로그 이미지

Bryan_

,