반응형

OS: Ubuntu 14.04 Desktop (amd64)

Device: NETIS WF2190 (Realtek RTL8812au) (802.11ac)


실험에 5GHz 대역으로 작동하는 IEEE 802.11ac를 쓰기 위해서 NETIS NF2190 무선랜카드를 꺼냈다.

대충 이렇게 생겼다.


 



우분투 머신에 USB로 연결했더니 바로 인식되지는 않았다.

lsusb에서는 인식되고 있기 때문에 드라이버만 설치하면 된다.


$ lsusb


...(생략)...

Bus 001 Device 005: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter

...(생략)


내 PC가 그동안 Atheros 계열 무선랜카드를 컴파일하는 데만 집중하느라 Realtek 계열 드라이버가 모두 날아갔을 수도 있고, 원래 인식이 안되는 것일 수도 있다. 아무튼 드라이버를 설치하기 위해서 동봉된 CD에서 linux 디렉토리에 있는 설치 파일이 들어 있는 디렉토리를 복사해 와서 설치를 시도했다.

최상위 위치에 있는 install.sh 실행했더니 중간에 빌드 에러 발생.


인터넷을 뒤져 보다가, 그냥 git에 있는 최신 코드를 가져와서 빌드하기로 했다. [1]


$ git clone https://github.com/gnab/rtl8812au.git

$ cd rtl8812au
$ make
$ sudo make install
$ sudo modprobe 8812au


make는 문제없이 됐다.

sudo make install 명령도 문제없이 되는 듯 했다.

하지만 sudo modprobe 8812au가 되지 않았다.

/lib/modules/($uname -r)/kernel/drivers/net/wireless/ 위치에 8812au.ko가 있는데도 실행이 안됐다.


make 과정 중간에 mcount가 없다는 경고 메세지가 있었고 에러가 아니길래 그냥 넘겼는데, 이게 실제 드라이버의 정상 실행을 막는 원인이었다.

확인해 보니 gcc 버전을 4.8로 바꾸면 해결된다고 한다. [2] 그러고 보니 퀄넷 시뮬레이션 때문에 gcc 버전을 낮춰뒀던 것이 생각났다. 

gcc 버전 변경: http://skylit.tistory.com/23



gcc 버전을 바꾸고 다시 make; sudo make install; sudo modprobe 8812au 를 했더니 랜카드가 드디어 인식이 되었다.

iwconfig 명령으로 새로 보이는 무선랜 인터페이스가 있는지 확인할 수 있다.


$ iwconfig


... (생략)

wlan7     unassociated  Nickname:"<WIFI@REALTEK>"

          Mode:Auto  Frequency=2.412 GHz  Access Point: Not-Associated   

          Sensitivity:0/0  

          Retry:off   RTS thr:off   Fragment thr:off

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

...(생략)




<참고자료>

[1] http://ubuntuforums.org/showthread.php?t=2258715

[2] http://askubuntu.com/questions/468758/modprobe-ndiswrapper-error


반응형
블로그 이미지

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_

,
반응형

OS: Ubuntu 14.04 (desktop, server 모두) amd64



우분투(또는 리눅스) 머신에 원격접속할 때 xrdp를 설치하면 RDP 클라이언트(e.g. 윈도우의 원격 데스크탑 연결)를 쓸 수 있어서 좋지만, 세부 설정을 수정하지 않고 그대로 둘 경우 다음과 같은 두 가지 문제가 발생한다.


  1. (우분투만 해당) 검은색 또는 회색 화면만 나온 채 가만히 있거나, 그 상태로 잠시 있다가 연결이 끊어짐.
  2. 매번 세션이 새로 생성돼서 이전의 작업 환경에 접근할 수 없음.


1번의 경우에는 우분투 기본 세션인 Unity에 버그가 있고 아직 해결되지 않아서 그렇다.

답답하지만 xfce4와 같은 다른 세션을 설치해서 써야 한다. [1]



이 글에서 해결할 문제는 2번이다. 사실 이것은 xrdp 기본 설정이 불친절(?)해서 기존 세션을 재활용하기 위한 옵션을 디폴트에서 볼 수 없기 때문이다.


즉, 원격 세션에서 로그아웃을 하지 않으면 매번 rdp로 로그인할 때마다 새로운 세션이 쌓여서 쓸데없이 메모리를 차지하게 된다. 그 뿐만 아니라 각 세션마다 실행시켜 둔 어플리케이션들도 다 그대로 살아있게 되므로 낭비도 이런 낭비가 없다.


물론 xrdp 설정에서 최대 동시 세션 수를 기본값 10으로 제한해 두기는 했다. 따라서 윈도우 rdp 클라이언트로 리눅스 머신에 10번 넘게 접속해서 세션을 만들기만 하면, 기존의 10개 중 가장 오래 된 세션이 고아 프로세스가 되거나, 아예 에러가 나면서 더이상 연결이 안되는 문제가 발생한다. 이런 문제를 방지한답시고 최대 세션 수를 100개(...)로 늘리라는 조언을 인터넷에서 심심찮게 볼 수 있는데, 그다지 좋은 방법이 아닌 것 같다.


물론 기존 세션을 쓰기 위한 옵션이라고 해봤자 결국 "포트 번호"를 입력하는 것 외에는 아무 것도 없다. ㅡㅡ; 즉, 기존 세션이 각자 포트 번호 하나씩 할당되어 있으니까 포트 번호만 외우고 있으면 나중에 다시 접근할 수 있다. 지금 생성돼 있는 세션과 포트 번호를 리스트로 보여주기라도 하면 좋을 텐데... 뭐 오픈소스니까 직접 그 기능을 코드로 만들어 넣지 않는 이상 너무 많은 것을 기대하지는 말자... ㅜㅜ





<XRDP 기존 세션 재활용 방법>


1. /etc/xrdp/xrdp.ini 파일을 열고, [xrdp1]에 해당되는 항목을 아래와 같이 고친다.


...

[xrdp1]

name=sesman-Xvnc

lib=libvnc.so

username=ask

password=ask

ip=127.0.0.1

port=ask5910

...


원래는 port 부분이 -1로 되어 있고, 로그인 창에서 보이지 않게 되어 있다. 하지만 ask를 추가함으로써 항상 접속할 때마다 포트 번호를 입력할 수 있도록 바꿨고, 그 뒤에는 5910이라는 포트 번호가 기본적으로 입력되어 있도록 설정했다.



2. xrdp 서비스를 재시작한다.


$ sudo service xrdp restart



3. 원격 데스크탑 연결(RDP) 클라이언트로 접속하면, 아래 그림과 같은 로그인 화면이 뜰 것이다.

원래 없던 포트 번호가 표시됨을 알 수 있다.



만약 리눅스 머신을 부팅한 직후 맨 처음 접속하는 경우거나, 기존에 생성된 세션의 포트 번호를 모르겠는 경우에는 아래와 같이 포트 번호를 "-1"로 고쳐서 로그인한다.


(새로운 세션을 만들 때에는 포트에 -1을 입력한다)


새로운 세션이 만들어질 때, 로그 메세지를 자세히 보면 세션이 어느 포트 번호에 할당되는지 알 수 있다. 해당 포트 번호를 기억해 둔다.

(새로운 세션이 포트 번호 5910번에 할당되었음을 알 수 있다.)


원하는 작업을 수행하고, 로그아웃하지 않은 채로 RDP 클라이언트를 종료한다.



4. RDP 클라이언트로 다시 리눅스 서버에 접속한다.

이번에는 로그인할 때 port 부분에 이전에 접속했을 때 할당된 포트 번호를 쓰고 로그인한다. 그러면 방금 전에 작업하던 세션을 그대로 볼 수 있다.





필자의 경우는 리눅스에 RDP로 접속할 때에도 윈도우 서버에 원격접속 하듯이 세션을 여러 개 만들지 않기 때문에, 부팅 직후 맨 처음에 세션을 만들 때 -1로 바꾸는 수고만 하고, 그 뒤에는 항상 맨 처음 시도하는 포트번호가 5910이기 때문에 기본값으로 5910번 포트가 입력되어 있도록 설정해 두었다.


현재로써는 앞으로 쓰기에 이게 가장 손이 덜 가는 설정이라고 생각한다. 하지만 xrdp가 조금 더 친절해져서 리스트 형태로 나열된 기존 세션 중 하나를 눈으로 보고 선택해서 로그인할 수 있도록 개선되면 정말 좋겠다.




<참고자료>

[1] http://yujuwon.tistory.com/entry/%EC%9A%B0%EB%B6%84%ED%88%AC-%EC%9B%90%EA%B2%A9-%EC%A0%91%EC%86%8D


반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04 Desktop



scp 명령으로 IP주소를 알고 있는 원격 리눅스 머신에 파일을 전송할 수 있는데, 이 때 콘솔 창 마지막에 실시간으로 전송 현황이 갱신되어 출력된다. 보통은 지금 전송하고 있는 파일명, 전송률(%), 전송 속도(KB/s, MB/s 등), 남은 시간 등의 정보가 출력된다.


ping의 경우에는 RTT 측정 결과가 새로운 라인으로 찍히기 때문에 콘솔 화면에 이전의 기록을 모두 볼 수 있는 반면, scp는 그런 것 없이 마지막으로 갱신된 정보가 이전 라인에 계속 덮어써지는 구조라서 이전 기록을 확인할 수 없다.


scp를 통해 전송중인 정보를 ping과 유사하게 line-by-line으로 기록으로 남기기 위해서는 다른 도구와 조합해서 써야 하는데, script가 유용하다고 한다 [1]. Script는 콘솔 창에서 변화가 생기는 것(?? 적당한 표현을 찾지 못함...)을 모두 기록하는 도구이다.


인용한 StackOverflow에 달린 두 번째 답변에 의하면, 아래와 같이 할 수 있다:


$ script -c "아웃풋을 기록하고자 하는 명령어" [아웃풋을_저장할_파일]


예를 들어,

$ script -c "scp [sending_file_location] [receiving_host_and_location]" scplog.txt


맨 끝에 아웃풋을 저장할 파일을 지정하지 않으면, 

콘솔의 현재 위치에 typescript라는 파일을 자동으로 생성해서 저장한다.



123.yuv라는 20MB짜리 파일을 Remote host에 전달했을 때, 

예제로 생성된 로그파일(scplog.txt)은 아래와 같다:


Script started on 2016년 05월 13일 (금) 오전 03시 30분 26초


123.yuv                                         0%    0     0.0KB/s   --:-- ETA

123.yuv                                        34% 7072KB   6.9MB/s   00:01 ETA

123.yuv                                        59%   12MB   6.7MB/s   00:01 ETA

123.yuv                                        84%   17MB   6.6MB/s   00:00 ETA

123.yuv                                       100%   20MB   6.7MB/s   00:03    


Script done on 2016년 05월 13일 (금) 오전 03시 30분 30초



Script로 ping 명령을 테스트해 보면 그냥 콘솔에서 보는 것과 똑같이 찍힌다. 자세한 원리는 모르겠지만 실제로 변화가 생긴 라인을 기록하는 것 같은데, 여러 라인에 변화가 생기면 여러 라인이 동시에 기록되는지는 아직 모르겠다.


어쨌든 SCP도 그때그때 눈으로 보고 속도를 메모하던 안습한 짓을 하지 않아도 돼서 다행이다. (=_=)



<참고자료>

[1] How to best capture and log scp output? http://stackoverflow.com/questions/202432/how-to-best-capture-and-log-scp-output



반응형
블로그 이미지

Bryan_

,
반응형

Host OS: Ubuntu 14.04.1 Desktop (amd64)

Host OS (이동 대상): Ubuntu 14.04 Server (amd64)

Guest OS: Windows 10 (64-bit)


개인 PC에서 개인용 윈도우10 VM 하나를 만들어서 KVM에서 돌리다가, PC의 디스크 속도가 받쳐주질 못해서 서버에 옮기기로 했다.


원래 개인 PC에서 VM을 쓰려고 했던 이유는 guest OS에 원격접속할 때 네트워크 지연 시간을 극단적으로 줄이려는 목적이었고, 실제로 지연 시간은 매우 적었지만 물리적인 하드디스크 1개에서 host OS (Ubuntu)와 guest OS (Windows 10)를 모두 써 보니 전체적인 속도가 느려지고 말았다. 안 그래도 디스크를 많이 쓰는 경향이 있는데 SSD도 아니라서 bottleneck이 되고 말았다. 그래서 같은 건물에 있어서 어차피 LAN의 범위 안에 있는 자원이 충분한 서버에 VM을 옮기기로 했다.


VirtualBox처럼 간단하게 이미지 파일만 복사하면 되는 것 같지는 않아서 찾아본 결과, 나와 같은 목적으로 VM을 다른 호스트 머신에 복사해서 성공한 사례가 있었다. [1]



정리하면:


1. clone 명령으로 옮길(==복사할) 이미지를 만든다. 사실은 새로 안 만들고 바로 옮겨도 될 것 같다. 

즉, 굳이 복사할 필요성을 못 느낀다면 원래 있던 VM 이름과 이미지 파일 위치, xml 파일 위치를 기억해 두고 바로 2번부터 시작한다.


# virt-clone --original=[원래 있던 VM 이름] --name=[새로 만들 VM 이름] -f [생성할 img 파일 위치] --mac [랜카드 맥주소]


예를 들어,

# virt-clone --original=testvm1 --name=newvm -f /var/lib/libvirt/images/skylit_newvm.img --mac 00:12:34:56:78:90



2. 기존 호스트 머신에서 방금 생성한 img 파일과 설정 파일(xml)을 새로운 호스트 머신에 옮긴다.

서로 네트워크로 연결돼 있다면 scp를 쓰는 게 제일 빠를 듯. 일반적으로 virt-manager에 의해서 생성되는 VM 이미지가 저장되는 위치는 /var/lib/libvirt/images/ 이다. (루트 권한으로만 접근 가능)그리고 xml파일은 /etc/libvirt/qemu/ 에 [새로 만든 VM 이름].xml 로 생성된다.


예를 들어, 아래 두 파일을 새로운 호스트 머신으로 옮긴다.

  • /var/lib/libvirt/images/newvm.img
  • /etc/libvirt/qemu/newvm.xml



3. 새로운 호스트 서버의 콘솔에서, virt-manager에서 인식할 수 있도록 새로 옮긴 VM 이미지를 추가한다.

$ virsh define /etc/libvirt/qemu/[옮겨온 VM 이름].xml



4. 이제 virt-manager를 실행하면 목록에 방금 옮겨온 VM 이름이 추가되어 있음을 확인할 수 있다.



<주의사항>


옮겨 가는 새로운 호스트 머신의 KVM 설정에 따라서 기존 호스트 머신에서 설정한 것이 작동하지 않을 수도 있다.

대표적으로 CPU 설정, 메모리 용량, display 설정 등이 있다. 


  • CPU는 가상 CPU로 특정 모델(e.g. Intel SandyBridge)을 지정해 두었는데 새로운 호스트 머신에서 해당 CPU 모델을 가상화하지 못할 수 있으므로, CPU 프로파일을 한번 확인해 볼 필요는 있다.
  • 메모리의 경우, [1] 에서도 언급되었듯이 물리적인 전체 메모리 용량을 넘어서는 등의 자원 할당 문제가 있는지 살펴봐야 한다.
  • Display의 경우, 필자는 기존 호스트 머신에서 SPICE 프로토콜을 썼는데 옮겨 가는 새로운 호스트 머신에 SPICE를 설치해 두지 않아서 virt-manager를 통해서는 화면을 볼 수 없었다. 하지만 네트워크 관련 설정에 문제가 없어서 원격 접속하는 데에는 문제가 없었다.




<참고자료>

[1] http://serverfault.com/questions/399835/clone-kvm-qemu-vm-to-a-different-server


반응형
블로그 이미지

Bryan_

,