'raspberry pi'에 해당되는 글 9건

OS: Raspbian Jessie

TC는 리눅스에서 트래픽 컨트롤 기능을 제공하는 도구이고, shaping (응용 레벨에서의 data rate 설정), scheduling (패킷 전송 순서를 조절), policing (arriving traffic에 대한 제어인 듯? 자세히는 모르겠음), dropping (들어오고 나가는 패킷에 대한 drop)을 지원한다.

이렇게 여러가지 기능이 있고, traffic shaping만 해도 사용하는 queue의 종류와 옵션 설정에 따라 다양한 목적 달성이 가능한데, 일단 내 실험에서는 말그대로 "특정 어플리케이션에서 내보내는 트래픽(outgoing traffic)을 원하는 대역폭으로 제한"을 거는 것만 필요하기 때문에 이와 관련된 가장 간단한 설정 방법만 정리하게 되었다.

<조건 생성>

1. qdisc 생성하기

어떤 경우에는 qdisc를 나중에 생성하는 경우도 있던데 그냥 먼저 만들어도 상관이 없으므로 먼저 만들어 두기로 했다.

HTB (HIerarchical Token Bucket)이라는 큐를 쓸 경우의 명령어는 다음과 같다.

[IFNAME]은 네트워크 인터페이스 이름, 

[ROOT_HANDLE_NO]는 루트 qdisc에 대한 핸들 번호(아이디) 이다.

default 뒤에 붙는 숫자는 별 의미가 없다. 아무 조건으로도 분류되지 않는 모든 트래픽이 1:12라는 클래스에 할당된다는 의미이고, 아직 tc를 가지고 1:12라는 아이디를 갖는 class를 만들지 않았기 때문에 아무 조건 없이 보통의 트래픽처럼 처리된다.

(예)

무선랜 인터페이스(wlan0)에 대한 qdisc를 1번으로 생성:

2. Class 생성하기

생성된 qdisc를 거쳐 가는 모든 트래픽을 분류하기 위해서, 분류되는 각 클래스와 그 클래스에 대한 조건(이 글에서는 traffic shaping만 설정하므로 bandwidth 제한)을 설정한다.

[CLASS_NO]는 새로이 traffic shaping을 적용할 클래스에 붙이는 번호이고, 원하는 대로 아무 번호나 붙여도 된다. 1부터 시작해서 증가시키면 별 문제가 없을 것이다.

참고로 qdisc 생성할 때 지정한 default 번호를 염두에 두고 설정해야 한다. Default traffic에 제한을 걸고 싶지 않다면 앞서 설정한 default 클래스 번호는(qdisc 예시에서 1:12) 피해야 한다.

[DATA_RATE]는 제한을 걸 bandwidth 표현이다. 만약 100 KB/s (초당 100 킬로바이트)를 허용하는 최대치로 두고 싶다면 100kbps 라고 써야 한다. 보통 우리가 알기로 kbps는 Kilobits per second인데 여기서는 Kilobytes per seconds로 쓰이고 있으므로(왜 그렇게 했는지는 모르겠지만...) 혼동하지 말아야 한다.

(예)

무선랜 인터페이스로 나가는 트래픽 중에서 최대 대역폭 200KB/s의 제한을 갖는 클래스를 5번으로 정의하고 생성:

3. Filter 생성하기

클래스를 먼저 만들고, 그 뒤에 특정 클래스로 패킷을 분류시켜서 traffic shaping 효과를 내기 위한 필터를 만든다. 필터는 source IP, source port, destination IP, destination port, traffic type (TCP, UDP 등), network interface 등의 조건으로 패킷을 분류할 수 있다.

SRC_IP는 source IP주소,

SPORT는 source port number,

DST_IP는 destination IP주소,

DPORT는 destination port 이다.

조건은 모두 match로 시작하고, 조건을 걸고 싶은 경우에만 match를 명시하면 된다. 즉, source port number 조건을 걸 필요가 없으면 match ip sport [SPORT] 부분은 없어도 된다.

(예)

무선랜 인터페이스로 나가는 트래픽 중에서 도착지 IP주소 192.168.4.8, 포트번호 22에 대해서 클래스 1:5로 분류하기:

참고로 다른 조건의 트래픽을 같은 클래스에 추가로 분류시킬 수도 있다. 192.168.4.8에서 포트번호 5001도 추가로 1:5에 분류하고자 하면:

각 명령에 대해서 아무 메세지가 출력되지 않고 쉘이 나오면 성공적으로 적용된 것이다.

<생성된 조건 확인>

생성된 qdisc, class, filter 설정이 올바른지 확인하려면 아래와 같이 입력한다:

실제 생성된 설정 예시:

<조건 삭제>

보통은 filter와 class를 삭제하면 설정한 트래픽 제한이 사라진다. 삭제는 생성의 역순으로 해야 한다. qdisc는 굳이 삭제하지 않아도 트래픽에 대한 조건은 모두 사라지므로, 향후 다시 설정하고자 하는 경우 클래스까지만 삭제하면 된다.

[FILTER_HANDLE]은 위의 생성된 조건을 확인할 때 표시되는 필터 핸들 번호(filter handle)이고, 필자의 경우에는 거의 다 800::800 부터 시작하는 번호가 할당됐다. 필터 핸들을 쓰지 않고, filter를 생성할 때 입력했던 라인을 그대로 가져와서 add만 del로 바꾸게 되면, 놀랍게도 그 외에 설정했던 필터들이 모두 다 같이 삭제되는 현상을 볼 수 있다. 왜 그런지는 모르겠지만, 같은 문제를 호소하는 질문과 그 해결책으로 필터 핸들 번호를 이용한 삭제 방법이 StackOverflow 페이지에 제시되어 있다 [2].

<조건 변경>

add 대신 change를 쓰면 기존에 생성한 조건을 변경할 수 있다.

qdisc는 바꿀 일이 별로 없으므로 넘어가고, 클래스의 경우는 이미 할당된 번호와 parent를 변경할 수는 없고 rate 조정은 가능하다.

(예)

기존에 생성한 1:5 클래스의 bandwidth를 50KB/s로 변경할 경우:

TC가 잘 설정되었는지 확인하는 방법 중 하나로, iperf를 쓰는 방법이 있다. iperf는 받는 쪽에서 -s 옵션으로 받는 패킷에 대한 통계를 내고, 보내는 쪽에서 -c 옵션과 목적지 IP주소를 입력해서 최대 bandwidth를 측정할 수 있다.

iperf의 기본 포트인 5001에 대해서 필터를 걸었더니, 보내는 트래픽이 처음에는 약 1.6Mbps로 전송되다가, 클래스를 수정한 뒤에는 약 400Kbps의 대역폭을 가짐을 볼 수 있다.

받는 쪽 예시:

받는 쪽에서도 보내는 쪽의 tc 설정대로 처음에는 약 1.6Mbps 정도의 incoming traffic을 보이다가, tc 설정을 변경한 이후에는 약 400Kbps 정도의 낮은 속도로 패킷이 도착했음을 확인할 수 있다.

<참고자료>

[1] HTB Linux queuing discipline manual - user guide, http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

[2] TC hashing filters - single rule deletion, http://serverfault.com/questions/330581/tc-hashing-filters-single-rule-deletion

OS: Raspbian Jessie

Kernel version: 4.1.7-v7+

Device: Raspberry Pi 2 Model B

라즈베리 파이에서 리눅스 커널 헤더를 apt-get 으로 설치하면, 현재 OS가 실행 중인 것보다 낮은 버전이 설치된다. 실제 사용중인 버전의 커널 헤더를 설치하려면, 홈페이지에 가서 직접 다운로드받아서 설치해야 한다. (이전 포스팅의 1.2 Raspbian용 linux headers 다운로드/설치 항목 참조)

문제는 이렇게 sudo dpkg -i로 헤더를 설치하면, 루트 권한으로 설치되면서 소스코드 파일의 퍼미션이 모두 루트만 읽고 쓸 수 있게 되어서 (아마도 600, -rw-------) 일반 유저 프로세스에서 접근할 수 없게 되는 것이다. 

이로 인해 아래와 같은 작업이 모두 루트 권한 없이는 불가능해진다:

• 커널 모듈을 비롯해서 리눅스 헤더를 참조해서 빌드하는 경우 (make를 sudo make로 해야 되는 상황... 따라서 생성되는 파일이 모두 owner가 root가 되어버린다)
• ctags 같은 vim 플러그인에서 리눅스 헤더 소스에 접근하지 못하게 됨 (permission denied 처리되면서 소스코드를 로딩하지 못함.)

일단 설치 자체가 루트 권한 없이 불가능하므로, 설치를 다 하고 나서 수동으로 퍼미션을 조정하기로 했다. 일단 리눅스 헤더 최상위 디렉토리 위치에서, 하위 디렉토리에 있는 모든 소스 파일에 644 퍼미션을 줘서 root가 아니어도 read-only 접근이 되도록 했다.

이렇게 했더니 하위 디렉토리에 접근 자체가 안된다. 

생각해 보니 디렉토리는 755 퍼미션(drwxr-xr-x)을 줘야 한다. ㅡㅡ;

다행히, 현재 위치에서 하위에 있는 모든 디렉토리의 퍼미션을 755로 변경하는 방법도 있다. [1]

<추가사항>

여기까지 하면 ctag 같은 작업에는 문제가 없지만, make는 여전히 안될 때가 있다.

가끔 make가 scripts 디렉토리에 있는 실행 파일을 써야 할 때가 있어서 그렇다.

scripts 디렉토리에 있는 실행 파일들도 디렉토리와 마찬가지로 755 퍼미션을 걸어 줘야 한다.

scripts 디렉토리 안에 실행파일이 아닌 소스 파일들도 있어서 소스 파일은 그냥 실행 옵션을 뺐다.

이제 sudo 없이 make도 잘 되고, ctags도 잘 작동한다. ^^

<참고자료>

[1] "How to chmod all directories except files (recursively)?", http://superuser.com/questions/91935/how-to-chmod-all-directories-except-files-recursively/91966

Model: Raspberry Pi 2 Model B

OS: Raspbian Jessie (2015.09.24)

Kernel: 4.1.7-v7+

gcc: 4.7.3

WLAN device: Netis WF2190 (RTL8812au)

라즈베리파이에 RTL8812au를 소스코드에서 빌드하는 순서는 PC에서 하는 것과 같고, 다만 Makefile 내용만 약간 수정하면 된다. [1]

<선행 요구사항>

*리눅스 헤더 소스가 설치되어 있어야 한다.

*그외 빌드에 필요한 패키지들이 필요할 수 있다. Make 과정에서 빌드 에러가 나는 경우 해당 에러를 없애줄 관련 소스코드를 설치하는 식으로 해야 할 듯.

*라즈베리파이가 인터넷에 연결되어 있어야 한다.

<참고: 라즈베리파이 리눅스 헤더 설치>

사실 커널 버전 4.1.7-v7+ 를 apt-get install에서 설치할 수 없다. 그래서 직접 리눅스 헤더 소스를 받아서 수동 설치해야 하고, 수동으로 설치하려면 특정 버전의 gcc와 dkms가 필요하다. 현재는 gcc-4.7을 필요로 하고 이것은 apt-get install로 되길래 설치했다.

헤더 소스 설치파일은 deb 파일로 되어 있어서 dpkg로 설치한다.

<RTL8812AU 드라이버 설치>

PC용 설치와 마찬가지로 git에서 드라이버 소스코드를 받는다.

Makefile을 열고 아래와 같이 일부분을 수정한다.

<참고자료>

[1] https://www.raspberrypi.org/forums/viewtopic.php?p=706261

OS: Raspbian Jessie

HW: Raspberry Pi 2 Model B

NIC: TP-LINK TL-WN722N (Atheros ath9k_htc)

라즈베리파이에 USB 무선랜 카드를 2개를 동시에 꽂아서 쓰면서, 편의를 위해서 각 인터페이스 이름(wlan0, wlan1, ...)에 네트워크 설정을 강제로 지정해 두었다. 예를 들어, wlan0은 hostapd를 돌려서 항상 AP가 되도록 하고, wlan1은 ad-hoc 모드로 다른 라즈베리파이와 네트워크를 구축하도록 하였다.

<문제 상황>

그런데 재부팅하고 나면 거의 매번 인터페이스 이름에 실제로 매핑되는 USB 무선랜카드가 달라지는 현상이 있었다. 인터페이스 이름에 할당되는 무선랜카드의 맥주소(물리적 주소, MAC address, HW address)가 재부팅할 때마다 랜덤하게 배정되는 것이다. 즉, ifconfig로 인터페이스 정보를 볼 때, 아래와 같은 출력 결과에서 HWaddr 영역이 서로 뒤바뀌는 일이 비일비재하게 나타났다.

(라즈베리파이 기본 설정에서는 NIC가 여러 개일 경우, 

부팅할 때마다 빨간색 표시한 HWaddr 부분이 랜덤으로 계속 바뀐다.)

일반적인 상황에서는 별 문제가 아닐 수도 있겠지만, 내 경우에는 이렇게 맥주소가 뒤바뀌는 현상 때문에 애드혹 네트워크(ad-hoc network)를 구성할 때마다 여간 불편한 일이 아닐 수가 없었다. 애드혹 네트워크 설정을 /etc/network/interfaces 파일에 해 두더라도, 실제로 통신이 가능해지기 위해서는 서로 ping을 주고받는 과정과 어느정도의 시간을 거쳐서 각자 ARP 테이블을 구성해야만 한다.

만약 모든 라즈베리파이의 wlan1 인터페이스를 애드혹 네트워크로만 쓰기로 하고, 각 wlan1 인터페이스의 맥 주소와 고정IP 주소를 가지고 수동으로 ARP 테이블에 등록하는 스크립트를 만들어서 부팅 때마다 자동으로 실행되게 한다면, 불편하게 ping을 여러 차례 날릴 필요 없이 애드혹 네트워크를 바로 사용할 수 있게 된다. 하지만 맥주소가 부팅할 때마다 뒤바뀌면 ARP 테이블을 수동으로 추가하더라도 엉뚱한 맥주소가 등록됨으로 인해서 통신을 할 수가 없다.

<해결 방법>

udev에 network rule을 추가하면 된다. [1]

참고로 우분투 데스크탑에는 기본으로 맥주소와 인터페이스 이름을 고정해서 기억하게 되어 있다.

아래와 같은 문법으로 파일을 수정하거나, 없으면 파일을 만들어서 추가한다.

ATTR{address} 부분에 랜카드의 맥주소, NAME 부분에 강제 지정할 인터페이스 이름을 입력한다.

<참고자료>

[1] https://wiki.archlinux.org/index.php/Network_configuration#Device_names

Model: Raspberry Pi 2 Model B V1.1

USB WLAN: TP-LINK TL-WN722N (Atheros ath9k_htc)

라즈베리파이를 무선 메쉬 네트워크의 메쉬 라우터로 만드는 과정에서, USB 무선랜카드 2개를 꽂으면 하나가 매우 자주 연결이 끊어지는 현상이 발생했고, 자세히 확인해 보니 아예 device driver가 죽었다가 다시 살아나기를 반복하고 있었다. 그 현상은 아래와 같이 demsg 화면에서 확인할 수 있다. 그림 속 빨간 색 글씨와 같은 에러가 대략 10여 초를 주기로 계속 발생한다. 즉, 겉으로 보면 USB 무선랜카드의 전원 LED가 10초를 주기로 꺼졌다가 켜지기를 반복한다. 당연히 네트워킹은 안 된다.

(2개 이상의 ath9k_htc 계열 USB 무선랜카드를 연결했을 때 자주 보게 되는 에러 메시지. 

저런 식으로 인터페이스 이름이 지속적으로 커져서 phy30이 넘은 적도 있었다... -_-)

5V/2A의 저전력에 의지하는 라즈베리파이 입장에서 USB 무선랜카드 2개를 동시에 쓰면 1개만 쓸 때에 비해서 아무래도 전력이 부족할 가능성이 높다. 게다가 알고 보니 내가 실험에 사용하는 TL-WN722N 모델이 USB 포트를 통한 전력 공급에 문제가 있는 것 같았다. 한 마디로 설상가상이다. ㅜㅜ 

어디선가 영어로 된 페이지에서 알려진 이슈로 위와 같은 현상이 언급되어 있었던 기억이 난다. 지금으로써는 비교할 만한 다른 ath9k_htc 계열 무선랜카드가 없어서 이것이 결함인지 아닌지 알 길이 없다. (그래도 어느정도 결함 수준으로 봐야 할 정도다.)

더 큰 문제는, 안그래도 전력을 많이 쓰는 녀석이 몸집마저 커서 Raspberry Pi 2 Model B에서는 두 개를 동시에 USB 포트에 직접 꽂을 수도 없다는 사실이다. 이것은 사실 라즈베리파이 2 모델의 디자인으로 인해서 생기는 문제이기도 한데, USB 포트 4개가 한 곳에 몰려 있기 때문에 연결되는 USB 객체가 조금이라도 크기가 커지면 연속으로 (심지어 대각선으로도) 꽂을 수가 없다.

그래서 아래 사진과 같이 하나는 USB 포트에 직접 꽂고, 다른 하나는 USB 확장 케이블을 통해서 연결해야만 했다.

그리고 예상대로, USB 확장 케이블(대략 1~1.5m 쯤 되는 듯)을 통해서 연결된 무선랜카드에서만 위의 dmesg 화면과 같이 디바이스 드라이버가 재시작하는 문제가 지속적으로 봘생했다. 어쩌다 한 번씩 멀쩡하게 작동하는 듯 했지만, 하루가 지나고 보면 어김없이 하나는 꺼져 있었다.

결국, 매번 재부팅시키고 아슬아슬하게 살아 있기를 바라기만 해서는 정상적인 실험이 불가능하다고 판단하고, 가장 무식하지만 가장 확실한(...) 물리적인 해결책을 사용했다. 그 무식한 방법은 그냥 뚱뚱한 껍데기를 뜯어내는 것 -_-;;

나사가 하나도 없기 때문에 가장자리에서부터 힘으로 열려고 노력하면 생각 외로 잘 뜯어진다(...).  

그 결과...

이제 동시에 무선랜카드 2개를 USB 포트에 직접 꽂을 수 있게 되었고, 신기하게도 디바이스 드라이버가 재시작하는 현상이 말끔히 사라졌다.

...다음부터는 Atheros 계열 무선랜카드를 살 때, 알려진 문제점이 없는지 좀더 검색해 보고 사는 것이 좋겠다. ㅜㅜ