i.MX8MP에서 TX700(Qualcomm MDM9207) LTE 모뎀 RNDIS 연결하기 — lsusb에 안 보이는 것부터 인터넷 연결까지

임베디드 리눅스 보드에 LTE 모뎀을 붙이는 작업은 "USB 꽂으면 되겠지"로 시작해서 커널 컨피그까지 내려가는 경우가 많다. 이번 글은 i.MX8MP(Yocto kirkstone) 커스텀 보드에 TX700 LTE 모뎀(Qualcomm MDM9207 기반)을 RNDIS로 연결하면서 겪은 과정을 정리한 것이다.

 

환경

• 보드: i.MX8MP 커스텀 보드
• BSP: Yocto kirkstone, 커널 5.15.x
• 모뎀: TX700 (Qualcomm MDM9207, LTE Cat.1급)
• 연결: USB

1. 증상: lsusb에 모뎀이 없다

전원 넣고 lsusb를 치면 이것만 보였다.

Bus 001 Device 001: ID 1d6b:0002   # 루트 허브
Bus 001 Device 002: ID 0424:2514   # SMSC 온보드 USB 허브
Bus 001 Device 003: ID 0403:6011   # FTDI FT4232H (쿼드 UART)
Bus 001 Device 004: ID 0b95:178a   # ASIX 이더넷

퀄컴 계열 모뎀이면 VID가 보통 05c6(Qualcomm)으로 뜨거나 벤더 자체 VID로 뜨는데, 어디에도 없다. 이 시점에서 갈림길이 생긴다.

1. 열거(enumeration) 자체가 안 되는 경우 → 전원, USB_BOOT 핀, 케이블, 하드웨어 문제
2. 열거는 되는데 드라이버가 안 붙는 경우 → 커널 컨피그 문제

이 둘을 구분하는 가장 빠른 방법은 dmesg -w를 켜놓고 모뎀 전원을 다시 인가하는 것이다. 열거 시도 로그조차 없으면 하드웨어 쪽, new high-speed USB device 로그는 뜨는데 인터페이스가 안 생기면 소프트웨어 쪽이다.

[여기에 실제 dmesg 로그 캡처 삽입]

2. 진단 도구 셋

이 과정에서 쓴 도구들. USB 디버깅 삼종 세트라고 불러도 될 정도로 자주 쓴다.

# 어떤 드라이버가 어떤 인터페이스에 바인딩됐는지 트리로 확인
lsusb -t

# udev 이벤트 실시간 감시 — 꽂고 뽑을 때 add/remove가 흘러나온다
udevadm monitor --udev --property --subsystem-match=usb

# 네트워크 인터페이스 생성까지 보려면
udevadm monitor --udev --subsystem-match=usb --subsystem-match=net

# 열거 과정의 컨트롤 전송(GET_DESCRIPTOR 등)까지 봐야 할 때
modprobe usbmon
cat /sys/kernel/debug/usb/usbmon/1u

lsusb -t가 특히 중요한데, 장치는 잡혔지만 Driver= 항목이 비어 있으면 "열거는 성공, 드라이버 부재"로 바로 판정할 수 있다.

3. 원인: kirkstone 기본 이미지에 RNDIS 호스트 드라이버가 없다

열거는 정상인데 네트워크 인터페이스가 안 생기는 상황. 커널 컨피그를 확인했다.

zcat /proc/config.gz | grep -iE "RNDIS|CDC_ETHER|USB_NET"

CONFIG_USB_NET_RNDIS_HOST가 빠져 있었다. Yocto kirkstone 기반 기본 defconfig에서는 RNDIS 호스트 드라이버가 모듈로도 안 들어가 있는 경우가 있다. 데스크톱 배포판에서는 당연히 있는 드라이버라 존재 자체를 의심하기까지 시간이 걸린다.

커널 컨피그에 다음을 추가하고 재빌드했다.

CONFIG_USB_USBNET=y
CONFIG_USB_NET_RNDIS_HOST=y
CONFIG_USB_NET_CDCETHER=y   # rndis_host가 의존

(모듈 =m로 빌드해도 되지만, 항상 쓰는 장치라 built-in으로 넣었다.)

재부팅 후 dmesg에 기다리던 줄이 떴다.

rndis_host 1-1.2:1.0 usb0: register 'rndis_host' at usb-...

4. IP 받아오고 실제 외부 통신 검증

udhcpc -i usb0     # 모뎀 내장 DHCP 서버로부터 사설 IP 수신
ip addr show usb0
ping -c 3 8.8.8.8

ping 응답에서 눈여겨볼 것이 TTL 값이다. 내 경우 ttl=111이 나왔는데, 이건 패킷이 여러 홉을 거쳐 진짜 외부(8.8.8.8)까지 갔다 왔다는 뜻이다. 만약 ttl=63이나 ttl=127처럼 초기값-1 수준이 나왔다면 모뎀 내부(1홉)가 대신 응답한 것이라, "모뎀까지만 통신되고 외부로는 못 나가는" 상태를 의심해야 한다. traceroute -n 8.8.8.8을 돌려보면 모뎀 게이트웨이 → 통신사 사설 대역 → 코어망 → 외부로 이어지는 경로가 눈으로 확인된다.

[traceroute 결과 캡처 삽입 예정]

5. RNDIS는 어떻게 동작하나 — AT 커맨드와의 관계

여기서부터는 연결 자체보다 원리 이야기. RNDIS를 처음 다루면 "이게 AT 커맨드를 알아듣는 건가?"라는 의문이 드는데, RNDIS는 AT 커맨드를 전혀 모른다. 완전히 분리된 세계다.

TX700 같은 모뎀은 USB composite 장치라서 케이블 하나에 여러 인터페이스가 실린다.

USB 케이블 하나
├─ Interface 0: DM(DIAG)   → 벤더 진단 프로토콜
├─ Interface 1: Modem(AT)  → 시리얼, AT 커맨드는 여기로만
└─ Interface 2+3: RNDIS    → 제어 + 데이터(이더넷 프레임)

RNDIS 자체는 딱 두 종류의 메시지만 다룬다. 초기화 시점의 제어 메시지(INITIALIZE_MSG, QUERY_MSG로 MAC 주소·링크 상태 질의 등)와, 이후의 데이터 메시지 — 44바이트 RNDIS 헤더 뒤에 이더넷 프레임을 통째로 실어 bulk 엔드포인트로 나르는 것. 프레임 안에 IP가 들었는지 ARP가 들었는지 RNDIS 계층은 관심이 없다. 말 그대로 "USB로 흉내 낸 이더넷 케이블"이다.

재미있는 지점은 LTE 망에는 이더넷이 없다는 것이다. PDN 베어러는 raw IP만 나른다. 그래서 모뎀은 단순 통로가 아니라 사실상 소형 라우터다. 호스트 쪽에는 가짜 이더넷 세그먼트를 연기하고(DHCP 서버, 게이트웨이 MAC, ARP 응답까지 모뎀 펌웨어가 처리), 망 쪽으로는 IP만 뽑아 내보낸다. usb0가 DHCP로 192.168.x.x를 받는 것도 전부 모뎀 펌웨어의 연기다.

AT 커맨드가 필요한 순간은 "케이블 반대편 라우터가 WAN에 붙어 있느냐"를 제어할 때다. PDN 세션(APN 접속)을 올리는 건 제어 평면의 일이고, 그 수단이 AT 포트다. 집 공유기에 비유하면 RNDIS는 LAN 케이블, AT 포트는 공유기 관리 콘솔이다. 펌웨어가 auto-connect 설정이면 콘솔 만질 일 없이 케이블만 꽂으면 된다.

6. 운영 단계에서 알아둘 것: LTE CGN 제약

연결에 성공해도 설계 단계에서 반드시 고려할 제약이 있다. 일반 데이터 요금제 회선은 통신사 CGN(Carrier-Grade NAT) 뒤에 있어서 사설 IP를 받는다. 의미하는 바는:

• 장비 → 외부 서버 방향(UDP/TCP 개시)은 문제없다
• 외부 → 장비 방향, 즉 장비가 서버 역할을 하는 인바운드 연결은 불가능하다
• 인바운드가 필요하면 고정 IP 전용 APN을 계약하거나, 장비가 VPN으로 아웃바운드 터널을 먼저 뚫어놓는 구조로 설계해야 한다

원격 장비 관제 시스템이라면 이 제약이 아키텍처를 결정한다. "장비가 주기적으로 서버에 접속하는" 폴링/유지 연결 구조가 기본이 되는 이유다.

정리

1. lsusb에 안 보이면 dmesg -w로 열거 여부부터 갈라라
2. 열거는 되는데 인터페이스가 없으면 lsusb -t의 Driver 항목과 커널 컨피그를 봐라
3. Yocto 기본 이미지에는 CONFIG_USB_NET_RNDIS_HOST가 빠져 있을 수 있다
4. ping TTL 값으로 "모뎀까지"인지 "외부까지"인지 구분하라
5. RNDIS는 멍청한 파이프, 의미 해석은 모뎀 내부 스택의 몫, AT는 별도 채널
6. CGN 뒤라는 사실이 시스템 아키텍처를 결정한다

---

i.MX8MP 커스텀 보드에서 실측한 내용을 바탕으로 작성했습니다. 질문은 댓글로 남겨주세요.