캐서린유나아빠님의 이글루

Wireless Distribution System (WDS)

유나아빠 — Fri, 23 Oct 2009 19:59:29 GMT

802.11 WDS는 wireless bridge 모드와 wireless repeater 모드의 두가지 중 하나로 설정된다.

wireless bridge 모드는 서로 분리된 복수개의 유선네트워크를 L2에서 연결하는 개념이다. 이 모드에서는 유선네트워크망의 연결지점들을 잡고 그 지점들에 AP(여기서는 라우팅 기능이 없는 순수한 L2디바이스)를 설치하여 그 AP들간에 L2 Ethernet 프레임을 transparent하게 전송하는 것이 주 목적이다. 이때 802.11 frame은 이를 송수신하는 두 AP의 MAC주소와 Ethernet 프레임에 실려있던 원래의 MAC주소까지 모두 네개의 MAC주소를 가지게 된다.

wireless repeater 모드는 무선네트워크에서 AP의 커버리지를 확장하는 개념이다. 이 모드에서는 라우터에 연결된 한개의 마스터 AP와 여러개의 슬레이브 AP로 구성하게 된다. 마스터AP와 STA간의 무선통신은 기존과 같은 방식으로 이루어지며, STA가 슬레이브AP와 연결된 경우 슬레이브AP는 마치 마스터AP인 것처럼 행동하며 마스터AP와 STA사이에 802.11 프레임을 포워딩한다. 이 때, 마스터AP와 슬레이브AP 사이에 주고받는 802.11 프레임은 (1)최종 송수신노드가 모두 STA인 경우 이 STA들의 MAC주소와 두 AP의 MAC주소를 포함해서 총 네개의 MAC주소를 (2)한쪽노드만 STA인 경우 이 STA와 두 AP의 MAC주소를 포함해서 총 세개의 MAC주소를 가지게 된다.

두 모드의 결정적인 차이점은 좀더 넓은 커버리지로 STA들에게 connection을 제공하기 위한 것인가 아니면 단지 유선적으로 분리된 두 네트워크를 가상적으로 연결하기 위한 것인가에 있다. 그리고, 단일 WDS에서는 모든 AP들이 동일한 채널과 SSID, 그리고 encryption 파라미터들로 동작하도록 되어있다.

802.3af and PoE (Power-over-Ethernet)

유나아빠 — Fri, 23 Oct 2009 14:34:10 GMT

네트워크를 구성할 때 비용적인 관점에서 큰 부분을 차지하고 있는 것이 배선(wiring)이다. 일반적으로 네트워크 장비는 데이터전송 케이블과 전력전송 케이블을 요구하는데 이 두 케이블을 하나로 합친 것이 PoE이다. 지금 현재 가장 널리 쓰이고 있는 규격으로는 802.3af를 들 수 있다.

10/100Mbps fast ethernet에서는 랜케이불 내부의 8개의 와이어 중에 1/2/3/6번만 사용하고 4/5/7/8번은 사용하지 않는다. 따라서 대부분의 10/100Mbps 네트워크 장비들은 4/5/7/8번에 전력을 전송하는 방식을 사용하고 있으며 이를 pre-802.3af 혹은 802.3af Mode B라고 한다. 이 방식의 장점으로는 구현이 단순하고 생산단가가 저렴하며 안정적으로 동작한다는 점을 들 수 있으나 단점으로 4/5/7/8번을 사용하는 새로운 데이터전송규격에는 적합하지 않다는 점을 들 수 있다.

반면에 나중에 등장한 1000Mbps gigabit ethernet에서는 케이블 내부의 8개 와이어 모두를 사용하기 때문에 기존의 방법대신 phantom power technique을 사용하여 데이터와 전력을 모두 전송하는 방법을 사용해야 한다. 1/2/3/6번 와이어로 데이터와 전력을 모두 전송하는 방식을 802.3af Mode A(혹은 legacy Cisco-powered)라고 한다. 이 방식은 상대적으로 구현이 복잡하고 PSE(Power Supply Equipment)의 전력전송모듈에 문제가 발생하는 경우 데이터전송에까지 영향을 줄수 있다는 단점이 있으나 케이블의 모든 와이어를 아무 제한없이 데이터 전송에 사용할 수 있다는 장점이 있다. 또한 10/100Mbps에서 4개의 와이어만으로 전력와 데이터전송이 가능하므로 필요한 경우 한개의 랜케이블로 두개의 10/100Mbps장비를 지원할 수도 있다.

"802.3af- compliant"라고 광고하는 장비들은 대개 802.3af Mode A와 B를 동시에 지원하며, 이 장비에 Mode B만을 지원하는 PSE를 사용하게 되면 이 장비를 기가비트 모드로 사용할 수 없게 된다. 어떤 PSE는 Mode A와 B를 동시에 지원하기도 하는데 가격도 고가이고 구하기도 쉽지 않은 편이다.

다른 한편으로 PoE는 active 방식와 passive 방식으로 구분할 수 있다. 모든 케이블은 약간의 저항을 가지고 있기 때문에 전송로가 길어질 수록 케이블에 더 많은 전압이 걸리게 되고 상대적으로 PD(Powered Device)에 적은 전압이 제공된다. active방식은 양쪽 전력송수신모듈이 서로 정보를 교환하며 케이블의 길이에 상관없이 최적의 전압을 유지하는 방식으로서 장거리 전송에 유리하다. 반면에 passive방식은 양쪽 모듈의 정보교환 없이 일방적으로 전력을 전송하게 되며 단거리 전송에 유리하고 단가가 저렴한 특징이 있다. 실제로 90%이상의 PD 네트워크 장비들은 PSE로부터 30미터 이내의 거리에 설치되기 때문에 대부분의 경우 passive 방식을 사용하게 된다.

ath9k

유나아빠 — Mon, 10 Aug 2009 14:57:44 GMT

여기에서는 compat-wireless-2009-06-25를 기준으로 한다. /driver/net/wireless/ath/ath9k 디렉토리에 위치하는 소스파일들은 아래와 같다.

ahb.c: Atheros AR71xx SoC를 위한 AHB 지원, CONFIG_ATHEROS_AR71XX에 의해 선택

ani.c/ani.h: ANI(Ambient Noise Immunity)에 대해서는 여기를 참조

ath9k.h:

beacon.c:

calib.c/calib.h:

debug.c/debug.h
debugfs관련코드. /sys/kernel/debug/에 ath9k와 ieee80211 디렉토리를 만들고 디버깅에 필요한 상태정보를 실시간을 업데이트한다.

eeprom.c/eeprom.h:

hw.c/hw.h:

initvals.h:

mac.c/mac.h:

main.c:

Makefile:

pci.c: PCI/PCI-E형태로 된 라디오 카드의 PCI관련 설정, CONFIG_PCI에 의해 선택

phy.c/phy.h:

rc.c/rc.h: STA의 ht_cap에 따른 rate table의 설정 및 PER기반의 rate control을 수행

reg.h:

virtual.c:

xmit.c/recv.c: 패킷 송수신

mac80211

유나아빠 — Fri, 07 Aug 2009 19:49:32 GMT

ieee80211_i.h: most internal data structures

main.c: main module entry points, main entry points for driver calls (reg/dereg)

iface.c: 가상인터페이스관리

key.*: 키관리

sta_info.*: Station (peer) management

pm.c: power management (suspend/hibernate)

rate.*: internal rate control functions

rc80211*: rate control algorithms

rx.c: frame receive path

tx.c: frame transmit path

scan.c: software scanning code

ht.c : HT(High Throughput)모드동작 관련
오리지널 코드에서는 ieee80211_ht_cap_it_to_sta_ht_cap()에서 잘못된 ht_cap_ie(HT capability)를 읽어서 HT20으로만 동작하도록 되어 있다. 이를 강제적으로 재설정하여 HT40으로 동작시키고 있다.

agg-rx.c/agg-tx.c: aggregation code

mesh.*/hwmp.*/plink.*/pathtbl.*: 7가지 동작모드 중 mesh 모드(802.11s)와 관련됨

mlme.c: Station/managed mode MLME

ibss.c: IBSS (ad-hoc) 모드와 관련된 MLME

cfg.*/wext.c: configuration entry points

event.c: events to userspace

spectmgmt.c: spectrum management code

aes*/tkip.*/wep.*/michael.*/wpa.*: WPA/RSN/WEP code

wme.*: some QoS code

util.c: utility functions

led.*: LED 제어

debugfs.* : debugfs code

802.11 in Linux

유나아빠 — Fri, 07 Aug 2009 15:16:14 GMT

Linux에서 네트워크디바이스를 동작시키기 위해서는 (1)유저레벨 API, (2)네트워크프로토콜스택(L2~L4), 그리고 디바이스를 직접 제어하는 (3)디바이스드라이버(L1~L2)가 필요하다. SoftMAC을 사용하는 무선랜디바이스(Atheros계열포함)에서는 자체 드라이버에 포함된 디바이스 고유의 L2프로토콜스택 혹은 리눅스의 mac80211이라는 공용 L2프로토콜스택과 함께 Wireless Extensions이라는 API를 사용하게 된다. (디바이스 고유의 L2프로토콜스택은 아예 디바이스드라이버의 일부로 생각하기도 한다.)

mac80211 (802.11 Protocol Stack)
2006년부터 John Linville의 주도로 개발되기 시작했으며 (초기에는 d80211로 불리우기도 했음) 커널 2.6.22부터 포함되었다. mac80211에서 AP(Access Point)모드동작은 hostapd를 통해 유저스페이스에 이루어지고 있지만 STA모드동작은 아직까지 커널스페이스에서 이루어 지고 있으며 조만간에 유저스페이스로 옮겨질 예정이다. mac80211은 멀티SSID지원을 위해 한개의 마스터인터페이스(wmaster*)와 한개이상의 가상인터페이스(wlan*)를 만드는 방법을 사용하고 있다. FullMAC을 사용하는 무선랜디바이스들의 경우 디바이스의 펌웨어/로직이 자체적인 L2프로토콜스택(MLME:MAC Layer Management Entity)을 포함하므로 mac80211을 필요로 하지 않고 자체적으로 동작한다.

Wireless Extensions (WE/WEXT)
1996년부터 HP랩의 Jean Tourrilhes라는 사람의 주도로 만들어진 API이며, 흔히 사용되는 iwconfig라는 커맨드명령어도 이 API에서 지원한다. WE는 유저스페이스와 커널스페이스간의 통신을 위해 ioctl함수를 사용하는데 이 함수는 몇가지 치명적인 문제점을 가지고 있어서 이를 대신하기 위해 현재 cfg80211/nl80211이 개발중에 있다.

cfg80211/nl80211 (WE Replacement)
cfg80211은 WE의 Configuration-API부분을 대신하여 무선랜디바이스의 설정을 담당한다. nl80211은 cfg80211과 유저스페이스를 연결하며 WE의 ioctl-based netlink 인터페이스를 대신한다. cfg80211은 디바이스등록을 위해 새로운 wiphy 구조체를 사용하며, 현재 iw, crda, hostapd, wpa_supplicant 등의 여러 애플리케이션이 이를 지원하고 있한다. OpenWrt에서는 libnl 풀버젼에서 netfilter관련부분과 rtnetlink를 뺀 미니버젼인 libnl-tiny을 함께 제공하고 있다.

madwifi/ath5k/ath9k driver
Atheros계열의 802.11a/b/g 디바이스를 지원하는 madwifi 드라이버는 자체적인 L2프로토콜스택과 하드웨어를 제어하는 HAL, 그리고 WE를 사용한다. 그러나 ath5k/ath9k는 L2프로토콜스택으로 공용 mac80211을 사용하기 때문에 간단한 low-level 부분만을 포함하며 디바이스를 기존madwifi의 HAL바이너리없이 직접 제어한다.

file_operations 구조체 에러

유나아빠 — Tue, 09 Jun 2009 15:13:37 GMT

file_operations구조체를 사용하는 부분에서 "has initializer but incomplete type"에러가 나면 이를 정의하는 "#include "를 삽입한다.

chillispot의 대역폭제어

유나아빠 — Wed, 29 Apr 2009 14:23:52 GMT

지금 우리가 쓰고 있는 chillispot을 대신할 hotspot 소프트웨어가 있는지 알아봐달라는 요청이 들어와서 먼저 chillispot의 기능들을 살펴볼 기회를 가지게 되었다. 가장 중요한 기능은 authenticiation이 되겠지만 OS레벨에서는 accounting이 가장 직접적인 연관성이 있다. accounting기능과 관련되서 라우터 OS에서 하는 일은 주로 사용자별 대역폭제한과 사용량측정이다. 일반적으로 리눅스에서는 imq나 ifb등의 가상디바이스를 만들고 이를 통해 outgoing packet의 양을 조절함으로서 대역폭을 제한하는 것이 가장 일반적이다. 그러나 수많은 유저들에 대해 일일이 가상디바이스를 만드는 작업은 엄청난 노가다일수밖에 없다. 그러나, chillispot에서는 인증서버에서 사용자별 최대대역폭 정보를 받은 후 하나의 가상디바이스(tun0)를 만들고 OS의 user-space상에서 이를 사용자별로 제어한다. 과연 user-space상에서의 대역폭제어가 디바이스레벨의 제어보다 더 효율적인지 궁금하다.

How to remove the original IXP4XX Ethernet driver from OpenWrt (r10958)

유나아빠 — Wed, 22 Apr 2009 14:34:39 GMT

(1) Delete the IXP4XX Microcode package
     rm -rf ./package/ixp4xx-microcode
(2) Remove Microcode package info (lines:645 to 661) from network.mk
     vi ./package/kernel/modules/network.mk
(3) Remove Microcode package info (Line 25) from ./target/linux/ixp4xx/Makefile
     vi ./target/linux/ixp4xx/Makefile
     #-DEFAULT_PACKAGES += ixp4xx-microcode
(4) Modify patch files in ./target/linux/ixp4xx/patches-2.6.24
     vi ./target/linux/ixp4xx/patches-2.6.24/200-npe_driver.patch
     rm ./target/linux/ixp4xx/patches-2.6.24/201-npe_driver_print_license_location.patch
     patch other files that include IXP4XX_ETH, IXP4XX_NPE, IXP4XX_HSS, IXP4XX_QMGR
(5) Modify config-default (Lines:190,192,194,197)
     vi ./target/linux/ixp4xx/config-default
     remove CONFIG_IXP4XX_ETH, IXP4XX_NPE, IXP4XX_HSS, IXP4XX_QMGR

IXP4XX Ethernet Driver (Access Library, NPE Library, and Ethernet driver patch)

유나아빠 — Mon, 20 Apr 2009 17:26:58 GMT

그동안 IXP425플랫폼과 OpenWrt를 사용하면서 왜 OpenWrt는 NPE Library만 포함된 반쪽짜리 Ethernet드라이버를 사용할까 궁금했었다. Snapgear나 DD-WRT 등의 다른 OS들은 모두 Access Library와Ethernet driver patch까지 포함된 풀버젼 드라이버를 사용해왔기 때문에 더더욱 그랬다. 이 덕분에OpenWrt상에서는 VLAN과 다른 많은 기능들이 불완전하게 지원되었고, 그동안 회사에서는 이 불완전한 드라이버를 패치하기위해 인턴을 고용하며 여러 달을 소비하였다.

그러다가 근 며칠동안 내가 직접 이 세 OS의 드라이버 부분을 비교하게 되었는데 예상과는 달리 Intel driverpackage는 의외로 간단하게 커널과 integrate될 수 있는 것을 발견하게 되었다. 결국 Makefile과 몇개의파일패치만으로 단 3일만에 OpenWrt에서 성공적으로 full package를 설치할 수 있었다. 그러나, 소스트리 관리부분에서는 OpenWrt svn 코드에서 기존의 반쪽짜리 드라이버를 완전히 제거하고 외부 패키지의 형태로 드라이버 코드를 설치해야 하는 작업이 필요하게 되었다. 결국 menuconfig상에서 드라이버를 커널 디렉토리에 복사해넣는 옵션과 이 드라이버를 컴파일하는 옵션 두가지로 작업을 진행중이다.

Atheros Driver

유나아빠 — Thu, 09 Apr 2009 20:29:40 GMT

그동안 madwifi 프로젝트를 접하면서 Atheros(발음은 아데로스가 아니라 에써로스)라는 회사가 얼마나 대단한 무선칩셋을 만들길래 이렇게 수많은 사람들이 이 칩셋을 기반으로 하는 madwifi driver에 관심을 가지고 있는지 궁금했었다. 그러다가, 드디어 오리지날 Atheros 드라이버 소스코드를 보게 되었는데 한마디로 충격이었다. ar231x SoC 칩셋을 장착한 ap61 레퍼런스모델용 드라이버는 madwifi 극초기형 버젼에 HAL소스를 더한 것이었다. (한마디로 최신 madwifi 드라이버가 훨씬 낫다.) 그나마 ar71xx/ar91xx 칩셋을 장착한 ap83 레퍼런스모델용 802.11n 드라이버는 자체 드라이버로 제작되었지만 2.6.17커널만을 지원하기 때문에 최신 2.6.28/29 커널과 컴파일하기 위해서는 엄청난 디버깅이 필요하다. (현재 사용중인 2.6.24로 컴파일하려고 디버깅하다가 포기...) 우리 회사의 드라이버 엔지니어 말로는 Atheros사는 가정용 무선라우터에만 관심이 있기 때문에 indoor 환경과 Atheros SoC 칩셋(w/single radio)만 지원한다고 한다. 그동안 outdoor환경 에서 802.11a(구체적으로는 OFDM-based modulation modes)의 range 문제때문에 고생을 많이 해왔는데 결국 이 문제도 Ambient Noise Immunization (ANI)라는, indoor 환경용 noise adaptation 기능때문으로 밝혀졌다. 결국, 최신 madwifi 드라이버에서는 Sam Leffler 등 많은 프로그래머들의 노력으로 이 기능을 소프트웨어적으로 끌수 있게 되었다.