Wi-Fi CSI 데이터 수집 Intel 칩셋과 드라이버 이슈 트러블슈팅

Wi-Fi 신호를 이용해 CSI 데이터를 수집하는 개발을 진행하며 겪었던 문제 해결 과정을 기록해보겠습니다

시작부터 막막했던 'Segmentation Fault'

처음 FeitCSI의 ./app을 실행했을 때, 저희를 반긴 것은 Segmentation fault 오류와 Bad spatial stream 경고였습니다. CSI 데이터 파일은 당연히 생성되지 않았습니다.

 

문제: 프로그램 비정상 종료, CSI 데이터 수집 불가.

진단 및 해결:

Monitor 모드 설정: Wi-Fi 트래픽을 수동으로 감지하려면 네트워크 카드가 'managed' 모드가 아닌 'monitor' 모드여야 합니다. iw 명령어를 사용해 모드를 성공적으로 변경했습니다.

 

# wlp3s0는 실제 인터페이스명으로 변경
sudo ip link set wlp3s0 down
sudo iw dev wlp3s0 set type monitor
sudo ip link set wlp3s0 up

올바른 명령어 문법: FeitCSI의 도움말(-h)을 통해 -i 옵션이 아니라, 인터페이스명을 첫 번째 인자로 전달해야 함을 확인했습니다.

# 잘못된 사용법: ./app -i wlp3s0 measureinject
# 올바른 사용법: ./app wlp3s0 measureinject

 

결과: Segmentaion Fault는 해결되었고, Injecting HESU... 로그가 뜨며 패킷 송신(TX)은 성공했습니다. 하지만 여전히 수신(RX)이 안 되어 CSI 파일은 생성되지 않았습니다.

 

사라진 Wi-Fi 카드와 'RF-kill'의 역습

단순한 설정 문제가 아니라고 판단, 시스템 깊숙한 곳의 호환성을 의심했습니다. 커널(v6.8)과 펌웨어(v86) 버전 불일치를 확인하고 최신 v89 펌웨어로 수동 업데이트를 진행했습니다. 그러자 더 큰 문제가 발생했습니다.

 

문제: iw dev 목록에서 Wi-Fi 인터페이스(wlp3s0)가 사라졌고, FeitCSI 실행 시 Operation not possible due to RF-kill 오류가 발생했습니다.

 

진단 및 해결:

RF-kill 상태 확인: rfkill list all 명령어로 확인하니, Wireless LAN이 **소프트웨어적으로 차단(Soft blocked: yes)**되어 있었습니다

RF-kill 해제: 아래 명령어로 모든 장치의 잠금을 해제했습니다

sudo rfkill unblock all

드라이버 재로드: RF-kill 해제 후에도 인터페이스가 바로 돌아오지 않아, Wi-Fi 드라이버를 수동으로 재시작했습니다.

sudo modprobe -r iwlwifi
sudo modprobe iwlwifi

결과: iw dev 목록에 wlp3s0 인터페이스가 성공적으로 복구되었습니다. 이제 CSI 데이터를 수집할 준비가 거의 끝났습니다.

 

"데이터를 얻었지만... 쓰레기였다" (잘못된 파서와의 사투)

드디어 masm csi 메시지와 함께 .dat 파일이 생성되기 시작했습니다! 하지만 기쁨도 잠시, 생성된 데이터를 Python으로 파싱하자 의미를 알 수 없는 값들만 가득했습니다.

 

문제: RSSI 값이 4286054241 처럼 비정상적으로 크고, MAC 주소는 f6:ff:0e:ff:3a:00 와 같이 유효하지 않은 패턴을 보였습니다.

진단 및 해결:

잘못된 추측: 문제의 원인은 CSI 데이터의 바이너리 구조를 추측에 의존해 파싱했기 때문입니다. 레코드 크기를 128바이트로 가정하고 만들었던 초기 파서는 실제 구조와 완전히 달랐습니다.

 

공식 문서 탐색: README.md 파일에서 공식 문서 웹사이트를 발견했고, 마침내 CSI 데이터의 정확한 구조를 설명하는 문서를 찾았습니다.

 

공식 문서에 명시된 272바이트 헤더 구조와 실제 CSI 데이터 (복소수 행렬) 형식을 기반으로 파서를 다시 작성했습니다. 그 결과, 정상적인 RSSI 값(-100 ~ 0 dBm)과 실제 주변 기기들의 MAC 주소, 의미 있는 진폭/위상 값을 얻는 데 성공했습니다.

 

최종 결론 및 핵심 교훈

CSI 데이터 수집 과정은 순탄치 않았지만, 각 단계를 통해 중요한 교훈을 얻을 수 있었습니다.

1. 기록의 중요성: dmesg, rfkill, iw dev 같은 기본 진단 명령어의 출력은 문제 해결의 가장 중요한 단서입니다.
2. 공식 문서를 신뢰하라: 바이너리 데이터 형식을 추측하는 것은 시간 낭비입니다. 언제나 공식 문서를 먼저 찾아 정확한 구조를 파악해야 합니다... 모르면 모를수록 더 파봐야합니다.. 무조건 AI에 내밀 문제가 아니었습니다
3. 문제는 복합적이다: 하나의 오류 메시지(RF-kill)가 해결되니 다른 문제(인터페이스 이름 변경)가 나타나는 것처럼, 문제는 연쇄적으로 발생할 수 있다는걸 알게되었고 차근차근 접근하는것이 중요하다는걸 또 한번 느꼈습니다 그래도 안된다? 되돌아가서 처음부터 분석해보자!

 

 

리눅스 환경에서 커널과 OS에 부착된 부가적인 모듈을 사용해 개발하는 엔지니어링 작업에 가깝지만 웹 개발과 다르게 생각보다 흥미로운 부분이 많았고 특히 리눅스 명령어가 반응이 없을땐 굉장히 당혹스러웠는데 무엇이 잘못됐는지도 나오지않고... 생각대로 안되면 스트레스를 많이 받는 분야인것같습니다 하지만 성공하면 그만큼 성취감은 돌아온😊