Julram's 개발 낙서장

- XMODEM

XMODEM은 시리얼 통신 매체를 활용하여 CP/M 플로피 디스크에 사용된 기본 블록 크기인 128Byte를 채택해 128byte의 데이터 단위 전송 및 프로토콜 규약으로 당시 모뎀을 통한 파일 전송을 보다 쉽게 만들기 위해 탄생했습니다.

XMODEM은 간단하면서도 신뢰성 있는 데이터 전송방식을 제공하여, 이후 YMODEM, ZMODEM 같은 확장 프로토콜이 탄생할 수 있는 기초가 되었습니다.

대부분의 파일 전송 프로토콜과 같이 XMODEM은 원래의 데이터를 일련의 패킷으로 쪼개어 수신자에게 보내며 여기에 추가 정보를 담고 있어서 수신자가 어느 패킷을 올바르게 받았는지를 결정할 수 있게 합니다.

128Byte 프로토콜에서 1Kbyte 형태로 발전하기도 했으며, Checksum 이외에 CRC16 형태로 확장되기도 하여 각 상황 및 설정에 맞춰 통신을 할 수 있도록 설계되어야 합니다.

이번 글에서는 XMODEM 프로토콜의 작동 방식과 패킷 구조, 전송 흐름을 알아보겠습니다.

- XMODEM 프로토콜의 기본 개념

XMODEM은 양방향 통신을 기반으로 하는 오류 검출 방식을 채택하여 데이터를 전송합니다.

특히 종단 간 오류 제어를 위해 체크섬(Checksum) 방식이 사용됩니다.

데이터 전송 시 오류가 발생하면 수신 측에서 오류 패킷을 다시 요청하여 재전송하는 방식으로 파일의 신뢰성을 유지합니다.

XMODEM은 전송 중 패킷 손실이나 손상된 데이터를 감지할 수 있어 당시 모뎀 환경에서 매우 유용했습니다.

- Data Packet Structure

XMODEM 패킷은 128바이트 크기의 고정된 데이터 블록으로 이루어져 있습니다.

각 패킷은 다음과 같은 형식으로 구성됩니다.

1. SOH (Start of Header): 1바이트, 패킷의 시작을 나타내며 ASCII 코드 0x01로 표시됩니다.
2. 블록 번호: 1바이트, 현재 패킷의 순서를 표시합니다. 0부터 시작하여 1씩 증가하며, 255를 넘어가면 다시 0으로 돌아갑니다.
3. 블록 번호의 보수: 1바이트, 블록 번호의 보수를 저장하여 오류를 검증하는 데 사용됩니다.
4. 데이터: 128바이트의 실제 데이터 내용입니다. 파일의 마지막 패킷에서는 부족한 바이트를 0x1A(EOF 문자)로 채웁니다.
5. 체크섬: 1바이트, 오류 검출을 위한 값으로, 데이터 필드의 모든 바이트의 합을 1바이트로 나타냅니다.

Checksum 과 CRC16 프로토콜의 차이는 Data Packet 이후 에러 검출을 위하여 Checksum 1 byte 또는 CRC16의 2 byte 에 따른 데이터 끝부분의 차이가 존재합니다.

- 기본 패킷(Checksum)

- CRC16 패킷

- Transfer flow

XMODEM 프로토콜은 간단하지만 규칙적인 전송 과정을 따릅니다. 송신 측과 수신 측이 데이터를 주고받는 과정을 단계별로 살펴보겠습니다.

1. 전송 시작 신호: 수신 측이 준비되면 ASCII 코드 0x15(NAK) 또는 0x43(C)을 송신 측으로 보내 파일 전송을 시작합니다. 이를 통해 송신 측은 수신 측이 준비되었음을 알 수 있습니다.
2. 데이터 패킷 전송: 송신 측은 각 데이터 블록을 패킷 구조에 맞추어 순차적으로 전송합니다.
3. ACK/NAK 확인: 수신 측은 패킷을 수신한 후 체크섬을 확인합니다. 오류가 없는 경우 ACK(0x16) 신호를, 오류가 있는 경우 NAK 신호를 송신 측에 보냅니다. NAK(0x15) 신호를 받으면 송신 측은 해당 패킷을 다시 전송합니다.
4. 파일 전송 완료: 모든 데이터 패킷 전송이 완료되면 송신 측은 EOT(End of Transmission) 신호를 보내 파일 전송을 마무리합니다. 수신 측이 EOT(0x04) 신호를 확인하면 전송이 끝났음을 인지하게 됩니다.

아래의 표와 같이 위에 설명한 수신 측에서 CRC의 경우 0x43('C')를 전송하여 전송측에 전송 요청을 보내어 통신 시작 및 싱크를 맞춰 진행합니다.

CRC 방식이 아닌 Checksum의 경우 0x15(NAK)를 보내어 시작합니다. 

전송 측으로 전달된 첫 패킷을 수신측에서 제대로 수신할 수 없는 경우 Checksum에서는 0x15(NAK)를 보내지만 CRC의 경우 0x43('C') 값을 보내야 합니다.

해당 상황에서 CRC 전송에서 첫 패킷에 0x15(NAK)를 보내게 될 경우 Tera Term 등의 프로토콜에서는 자동으로 Checksum으로 전환되니 해당 시퀀스에 대해 주의해야 합니다.

전송 시작 이후 SOH 와 각 Data Format에 맞춰 파일 데이터를 수신하며 Checksum 또는 CRC 패킷을 통해 Data 오류 검출 및 정합성을 확인하여 파일 데이터를 수신하고 EOT를 수신하게 되면 통신이 모두 종료되게 됩니다.

결론

XMODEM은 초기 파일 전송 프로토콜로서 통신 기술 발전에 중요한 기여를 했습니다.

이 프로토콜은 기본적인 오류 검출 기능을 통해 파일 전송의 신뢰성을 보장하며, 데이터 통신의 기초 개념을 잘 보여줍니다.

XMODEM을 이해하면, 이후 발전한 다양한 프로토콜의 배경과 원리를 쉽게 이해할 수 있습니다.

이상으로 XMODEM의 개념과 작동 방식을 알아보았습니다.

RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.

Git 및 Git LFS 등을 사용하여 빌드되는 경우 큰 파일 또는 TLS 값 에러가 발생하는 경우는 파일 수령 시 파일 크기가 Git 설정보다 클 경우 깨지게 된다.

해당 부분을 해결 또는 회피하기 위하여 Git File Buffer 사이즈를 늘려 큰 파일을 받는데 문제가 없도록 수정해야 한다.

하기의 Config 를 참고로 버퍼 크기를 수정하도록 한다.

ex) git config --global http.postBuffer 1048576000

     또는 SSL Verify false --> git config http.sslVerify false 까지 추가

svn Repository 내에서 git 으로 이전 시 사용 되는 명령 내용 정리

git remote add origin (git 주소)

git svn clone svn://(svn 주소) -A users.txt --username (user id) --no-metadata

git push --set-upstream origin master --force

--no-metadata --> git-svn-id 태그 생성 막음

svn users.txt

user_id = user_name <user_id@email.com>

일반적인 리눅스 환경 및 Server에서는 history 명령 및 설정에 의해 각 경로의 .bash_history에 명령 내용이 저장되고 부팅 시 불려지게 된다.

임베디드 환경이나 설정이 정상적으로 되어있지 않은 경우에는 정상적으로 저장되지 못하는 경우가 발생하는데,

이를 해결 하기 위해서 하기의 명령어들을 설정해 주어야 한다.

크게 3가지로 하기의 환경변수를 /etc/profile 또는 유저 디렉토리 내의 .bash_profile에 내용을 추가해준다.

1. HISTFILE : history 명령 및 shell command 내용을 기록할 파일
                 대부분의 경우에는 export HISTFILE=/home/$USER/.bash_history 로 설정된다.

2. HISTFILESIZE 또는 HISTSIZE : HISTFILESIZE의 경우에는 파일의 크기를 나타내며, 후자의 경우는 라인수를 지정한다.

       HISTSIZE의 경우 default 값은 500 이다.

       export HISTSIZE=500 또는 HISTFILESIZE=1000

3. 명령행 실행 시 저장 관련 :  export PROMPT_COMMAND="history -a; history -c; history -r; ${PROMPT_COMMAND}"

위 명령을 추가하여 쉘을 통해 명령 실행 시 저장될 수 있도록 지정해준다.

위 내용들이 정상적으로 적용되어 있는지 경로가 맞는지 확인은 쉘에서 echo ${env} 하여 확인하여 설정을 확인 한다.

ex)

echo $HISTFILE

echo $HISTFILESIZE or $HISTSIZE

echo $PROMPT_COMMAND

Rockchip AP는 세가지의 Booting Mode를 가지고 있으며, BootLoader 가 이상이 있거나, 업데이터를 이용하여 업그레이드가 불가능해졌을때 Mask Rom 모드를 통하여 수정하거나 하는 등의 동작 수행이 가능하다.

Rockchip AP의 부팅 순서는 다음과 같다.

1. power-up initialization (전원 인가)

2. 특정 저장장치 안의 부트로더를 확인하기 위하여 BootRom code를 SRAM 에서 동작 시킨다.

3. 부트로더가 확인 된 후, 부트로더의 부트 코드를 불러와 실행한다.

4. 부트로더의 부트 코드는 DDR 메모리를 초기화 하고, 부트로더의 전체 코드를 초기화된 DDR 메모리로 적재하고 부트로더를 실행한다.

5. 부트로더가 지정된 주소로부터 커널을 읽어 램에 적재하고, 커널로 점프 및 실행 한다

Loading Mode

Rockchip에는 BootRom 과 내부 SRAM을 통해 초기화 코드가 진행된다. 초기화 동작 및 하기의 메모리들로 부터 데이터를 읽어 들일 수 있도록 로드한다.

• 8-bit Async Nand Flash

• 8-bit toggle Nand Flash

• SPI interface

• eMMC interface

• SDMMC interface

추가적으로, 이 펌웨어는 USB OTG 인터페이스를 통해 다운로드 및 변경이 가능하다.

Boot Mode

Rockchip AP는 크게 세가지의 부팅 모드를 지원한다.

• Normal mode
  : 일반적인 startup procress로, 각 필요 요소들을 로드하여 시스템을 정상적으로 부팅하는 모드
  
  

• Loader mode
  : 부트로더에서 업그레이드 상태로 전환하고 호스트의 업그레이드 명령을 기다린다. 일반적으로 부트로더를 통하여 업그레이드가 필요한 상태일 경우 접근하는 방법
  
  이 모드로 전환하려면, 지정된 RECOVERY KEY를 눌러 부트로더에서 해당 Pin을 체크하여 전환한다. 또한 지정된 USB OTG 포트가 연결되어 있어야 한다.
  
  

• MaskRom mode
  
  : MaskRom mode는 부트로더가 정상적이지 않을 시 시스템 복구에 사용된다.
  
  일반적으로, BootRom 코드는 MaskRom mode로 전환되지 않으며, BootRom 코드 동작 시 부트로더가 읽을 수 없거나 손상으로 인하여 확인할 수 없는 상황에서만 진입이 가능하다.
  
  그 후 BootRom 코드는 USB interface를 통하여 Bootloader code가 전송되는 것을 기다리며, 인식된 Host PC 에서 로더 및 코드를 USB를 통하여 전달되면 실행되며 Loader 모드와 같이 업그레이드 할 수 있는 상태로 전환된다.

참조 : http://opensource.rock-chips.com/wiki_Main_Page

smbd 실행 시 Out of Memory 또는 실행이 되더라도 정상적으로 동작하지 않을때, 디버깅 및 실행에 관련된 사항을

확인하기 위하여, smbd 를 foreground 및 stdout 옵션을 주어 실행되는 내용을 확인한다.

$ smbd -F -S --debuglevel 3

위와 같은 메세지가 출력되는 것을 확인 할 수 있으며, 아래와 같이 top 으로 확인 시 메모리가 계속해서 누수가 발생하여, 결국 Out of Memory 로 인해 커널에서 프로세스가 죽게된다.

이런 경우, 위의 Debug 메세지와 같이 iconv 에서 변환하려는 과정에서 Memory Leak 이 연속적으로 발생하게 되고,

메모리 한계치에 도달하게 되면 위와 같이 프로세스가 강제로 죽게된다.

이 문제점을 해결하기 위해 /etc/samba/smb.conf 에서 아래의 옵션을 추가하여 iconv 함수 내에서 memory leak을 우회하여, samba가 정상적으로 동작 할 수 있도록 설정하여 막을 수 있다.

dos charset = UTF-8
display charset = UTF-8

위의 옵션을 추가하여 재실행을 하거나, cp850.so 파일을 생성하여 해결이 가능하지만, utf-8 로 손쉽게 처리가 가능하다.