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

예) target 디렉토리를 r14로 되돌리는 경우

mv ./target ./target.old
svnadmin create ./target
svnadmin dump -r 1:14 ./target.old --incremental > dump.svn
svnadmin load ./target < dump.svn
rm -rf ./target.old
trac-admin ./xos resync     (trac을 사용하는 경우에만)

If it shows an error, check the version of python.

SVN 사용법: http://svnbook.red-bean.com

RedBoot(레드부트)는 Redhat(레드헷)사의 Real-Time Embedded OS인 eCos를 기반으로 하는 부트로더이다. (특히, ARM프로세서를 사용하는 Embedded Board들의 대부분은 RedBoot를 표준 부트로더로 사용한다.) RedBoot는 원래 리눅스와 무관한 eCos를 지원하기 위해 만들어졌으나, 지금 현재 리눅스를 포함한 여러가지 유닉스 계열 OS들과 함께 광범위하게 사용되고 있다.

RedBoot는 커널 이미지를 로딩하기 위하여 다양한 방법을 지원하는데, 내/외장 플래시 메모리, HTTP, TFTP, X-/Y-MODEM 프로토콜 등을 옵션으로 사용할 수 있다. 그러나, 우리 회사가 사용하는 Pronghorn Metro 보드에 기본으로 설치되어 있는 RedBoot는 CF카드 상에서 EXT2 파일시스템만을 지원하기 때문에 Windows나 Mac OS를 주로 사용하는 네트워크엔지니어들에게는 큰 골치거리였다. 따라서, FAT을 지원하는 새로운 RedBoot가 요구되었고 기왕이면 최신버젼의 코드를 이용해 다른 다양한 기능들을 부가적으로 사용하는 일석이조의 효과를 얻으면 좋지 않을까 싶어서 새로 일을 시작하게 되었다.

우리가 기존에 사용하던 RedBoot의 DISK 패키지에는 EXT2와 관련된 파일만 들어 있다. 따라서, CYGSEM_REDBOOT_DISK_FAT* 옵션을 사용할 경우 find_partitions() 함수에서 redboot_fat*_funs를 찾지 못하고 에러를 낸다 [1]. 따라서, 다른 패키지 옵션을 사용해야 하는데 FILEIO 패키지를 이용하면 eCos의 FAT 지원기능을 사용할 수 있다 [2]. FILEIO 패키지는 다른 여러 패키지와 함께 설치되어야 하는데 이 과정이 자동적으로 진행되지 않으므로 .ecm파일에 이를 수동적으로 입력시켜야 한다. 기본 옵션 외에 내가 추가로 사용하는 옵션은 다음과 같다.

package CYGPKG_POSIX current ;
package CYGPKG_KERNEL current ;
package CYGPKG_ERROR current ;
package CYGPKG_IO current ;
package CYGPKG_IO_FILEIO current ;
package CYGPKG_DEVS_DISK_IDE current ;
package CYGPKG_FS_FAT current ;
package CYGPKG_LINUX_COMPAT current ;
package CYGPKG_LIBC_STRING current ;
package CYGPKG_BLOCK_LIB current ;
package CYGPKG_DEVS_DISK_ECOSYNTH current ;

이 옵션으로 redboot_*.srec 파일을 빌드한후 이 이미지로 부팅하면 RedBoot에서 fs 명령어를 사용할 수 있다. fs에서 인식하는 장치중에 "flash"는 On-Board Flash를 말하며 (jffs2 패키지로 마운트 가능), 우리가 마운트해야 할 장치는 CF카드를 나타내는 "idedisk0"이므로 아래과 같이 마운트하면 된다. 참고로 LFN(Long Filename)기능은 아직 활성화되지 않은 상태이며 상용버젼인 eCosPro에서만 지원되는 것으로 알려져 있다 [3]. (아직 확인은 못해봤다.)

RedBoot> fs info                                                                
Filesystems available:                                                          
fatfs                                                                           
                                                                                
Devices available:                                                              
/dev/flash/                                                                     
/dev/idedisk0/
RedBoot> fs mount -d /dev/idedisk0/1 -t fatfs
RedBoot> fs info                                                                
...
Mounted filesystems:                                                            
            Device               Filesystem Mounted on                          
                 /dev/idedisk0/1      fatfs /    
RedBoot> fs list                                                                
-65536 ----------  1 size     -1 B.                                             
6356992 ----------  1 size 7012409 <Not a string: 0x183000>                     
   3 ----------  1 size 3679888 OPENWR~1.ZIM                                    
 904 ----------  1 size     49 AIAFXRAM.RBS 
RedBoot> load -r -v -b 0x800000 -m file /OPENWR~1.ZIM
RedBoot> exec

이제 FAT을 쓸수 있게 되었지만 여전히 남아 있는 문제는 자동 부트스크립트 실행 문제이다. Pronghorn Metro의 RedBoot는 CF카드의 EXT2 파티션에 AIAFEXEC.RBS라는 스크립트 파일이 있을 경우 이를 자동으로 실행시키는 패치가 되어 있다. (AIAFEXEC: Application-In-A- Flash EXECution) 그러나, 이 기능은 DISK 패키지와 함께 사용되므로 FILEIO 패키지에는 곧바로 적용되지 않는다. 이 기능을 FILEIO와 함께 활성화시키려면 cyg_start()에서 현재의 파일시스템을 검사한후 FAT으로 판별될 경우 이를 자동적으로 마운트시키고 스크립트 파일을 읽어온 다음 이를 script 변수에 저장하는 패치가 추가적을 이루어져야 한다.

이제 ath9k 드라이버도 상당히 안정화가 되었고 지금 회사에서 802.11a/g와 함께 쓰고 있는 Pronghorn Metro 라우터보드가 802.11n을 충분히 지원할 만큼 성능이 뛰어난 편도 아니라서 슬슬 차세대 플랫폼을 생각해볼 때가 되지 않았나 싶다.

현재로서는 Intel Atom Z5XX, Marvell Sheeva, PowerPC계열 등을 후보로 고려하고 있는데 아직 밀리터리스펙(주로 동작온도범위가 관건; fan없이 -20C~+75C)을 지원하는 multi-PCI-slot 라우터보드제품이 전무한 형편이다. Atom Z5XXPT계열은 주로 멀티미디어 애플리케이션용으로 설계되었고 miniPCI-E만을 지원하는데 실제로 miniPCI-E slot을 가지는 보드도 드문 편이다. (아직 miniPCI-E로 쓸만한 고출력 Radio가 나오지 않고 있다.) Marvell Sheeva의 경우 ARM과 호환되며 최대 1.2GHz Dual-Core라는 엄청난 스펙을 자랑하지만 SMP프로세서가 아니라는 얘기가 있다. 예전에 Gateworks라는 회사에서 이를 이용한 보드를 개발하고 있다면서 샘플을 보내주겠다는 메일을 받았는데 그 이후 연락이 없는 것을 보니 지금은 포기상태인 것 같다[참조]. 지금 Sheeva 프로세서는 주로 SheevaPlug라는 플랫폼에 사용되고 있는데 주용도는 USB 저장장치를 네트워크 저장장치로 변환해주는 역할이다. PowerPC의 경우 아직 1GHz이상의 Embedded 프로세서 제품이 나오지 않고 있다.

다른 한편으로 802.11n지원을 위한 과도기적인 플랫폼으로서, 요즘 유행하는 AR7161@680MHz기반의 중저가 라우터보드들도 괜찮지 않을까 싶어서 MikroTik과 Ubiquiti Networks의 보드 몇개를 사다가 테스트중에 있다. 이중 Ubiquiti Networks사의 RouterStation Pro라는 보드가 가장 마음에 드는데 그 특징은 다음과 같다.

    *  Processor: Atheros AR7161@680MHz
          - 32-bit MIPS 24Kc core
          - Two Gigabit Ethernet MACs included
    * ROM: 16MB on-board flash
    * RAM: 128MB DDR
    * LAN: Two Gigabit Ethernet ports (1+3)
          - eth0 (WAN) supports 802.3af 48V POE. Using wit a 802.3af Mode-B POE injector disables Gigabit.
          - eth1 (LAN) is internally connected to an AR8316-based 6-port Gigabit switch.
                + Only 4 ports are physically enabled on board (3 external + 1 internal ports). 
    * Mini-PCI: Three slots
          - One slot is located on the bottom side. 
    * External Storage: SD
    * USB: One 2.0 port
    * Serial: Two connectors (118200/8/N/1)
          - One DB9 (crossed internally)
          - One 6-pin header (3.3VDC/S_in/NC/NC/S_out/GND) 
    * JTAG: 14-pin Header
    * GPIO: 7-pin Header
    * Reset Button: SW button based on GPIO_8
    * DC Power Jack: 40VDC ~ 56VDC
          - 3W idle w/o radio, 7W while passing Gigabit traffic
          - Some people say it also works stably with 12VDC or 24VDC. 
    * Temperature Range: -30C ~ +75C

iperf로 UDP패킷포워딩 테스트를 해보니 Gigabit의 경우 (eth0과 eth1사이) 260Mbps, 802.11n으로는 (R52N라디오사용) 단방향 140Mbps 양방향 90+90Mbps 정도 나오고 있는데, 특히 802.11n의 경우 100Mbps Fast Ethernet 성능에 근접한다 (AP에서 HT40모드로 설정이 안되길래 ath9k 드라이버문제인 줄 알고 힘들게 패치를 했는데 결국 hostapd문제여서 공식적인 패치가 이루어졌다는 nbd의 답변을 들었다[링크].)

하지만 이 보드도 몇가지 해결해야 할 이슈가 있다.

첫째, 인스톨된 RedBoot에서 SD Card Reader를 지원하지 않는다. 아직 내부 다이어그램이 공개되지 않은 관계로 확실한 것은 아니지만 SD Card Reader가 내부에서 USB로 연결되어 있어서 RedBoot에서 지원하려면 많은 패치가 필요하다는 얘기가 있다. Ubiquiti Networks forum에 질문이 올라와 있지만 아직 답변이 없는 상태이다[링크].

둘째, 6-pin serial connector의 RX pin이 동작하지 않는다. DB9을 GPS모듈에 물리거나 다른 용도로 사용할 경우에 결국 6-pin connector를 사용해야 하는데 이 connector로는 외부에서 output을 읽기만 할뿐 input을 보낼수가 없다. 같은 USB-to-Serial 컨버터로 LiteStation-SR71에는 잘 동작하는 것을 보면 뭔가 문제가 있는 것 같다.

셋째, Gigabit를 지원하기 위해서는 802.3af (Mode A) POE Injector가 필요한데 아직 회사에서 이를 써본 적도 없고 제품도 가지고 있지 않다. (만일 기존의 Mode B Injector를 쓰는 경우 eth0가 100Mbps Fast Ethernet으로 다운그레이드된다.) 결국 가까스로 48VDC 어댑터 두개를 구해서 쓰고 있지만 이미 설치된 AP Tower를 업그레이드할때 POE Injector도 함께 해야하는 문제가 있다.

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 파라미터들로 동작하도록 되어있다.

네트워크를 구성할 때 비용적인 관점에서 큰 부분을 차지하고 있는 것이 배선(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 방식을 사용하게 된다.