OpenCV를 이용하여 이미지 처리 및 웹 관련 에 관심있는 개발자

2 분 소요

MYD-YA157C 보드 블루투스 테스트 기록

WiFi 동글 드라이버까지 해결한 뒤, 이어서 온보드/USB 블루투스 두 어댑터를 테스트하고, Windows PC와 실제 데이터 통신까지 시도한 과정을 정리한다.

1. 블루투스 어댑터 확인

hciconfig -a

두 개의 어댑터가 확인됐다:

  • hci0: Bus UART, Broadcom BCM43430A1 (온보드, WiFi와 콤보 칩)
  • hci1: Bus USB, Realtek RTL8723B (USB 동글, 앞서 WiFi 드라이버 빌드했던 그 칩)

둘 다 UP RUNNING 상태로 정상.

2. 기본 스캔 테스트 — 하드웨어 레벨은 문제없음

hcitool -i hci1 scan

78:F2:38:58:DD:79    정훈의 A23

휴대폰이 바로 잡혔다. 하드웨어/드라이버/전파 송수신은 문제없이 확인됨.

3. bluetoothctl이 컨트롤러를 못 보는 문제

bluetoothctl로 넘어가자 문제가 시작됐다.

[bluetooth]# power on
No default controller available
[bluetooth]# list
(빈 값)

hciconfig는 정상인데 bluetoothctl(BlueZ D-Bus 클라이언트)만 아무것도 못 찾는 상황.

3.1 journalctl로 이력 확인

journalctl -u bluetooth -n 50 --no-pager

확인해보니 2019년 최초 부팅 때부터 지금까지, bluetoothd가 단 한 번도 컨트롤러 등록 로그를 남긴 적이 없었다. Management 인터페이스는 초기화된다고 나오는데 실제 컨트롤러 인식 로그가 전혀 없었음.

3.2 초기화 스크립트 확인 (원인 오판)

hciattach(레거시) 방식 때문일 거라 추측하고 /etc/init.d/bluetooth를 확인했으나, 실제로는 HCIATTACH 변수만 선언되어 있고 사용되는 곳이 없었다. 즉 이 스크립트가 원인이 아니었다.

3.3 btmgmt로 커널 레벨 직접 확인 — 반전

btmgmt info

결과: 두 컨트롤러 다 mgmt 인터페이스에 정상 등록되어 있고, powered connectable discoverable bondable ssp br/edr le secure-conn 설정까지 이미 활성화된 상태였다. 커널 레벨은 전혀 문제가 없었던 것.

3.4 진짜 해결책: bluetoothd 재시작

커널 mgmt 상태가 정상인 걸 확인한 뒤, bluetoothd를 다시 재시작하자:

systemctl restart bluetooth
bluetoothctl list

[NEW] Controller 9C:B8:B4:B2:90:2B localhost.localdomain #1 [default]
[NEW] Controller 48:8F:4C:32:B1:24 localhost.localdomain

드디어 정상 인식. 결국 커널/드라이버 문제가 아니라, bluetoothd가 mgmt 상태 변화(우리가 hciconfig로 이런저런 설정을 만지던 과정)를 실시간 반영하지 못하고 있던 타이밍/캐시성 문제였던 것으로 보인다.

4. 이름 설정의 함정

hciconfig hci0 name "..."로 바꿔둔 이름이, bluetoothd가 컨트롤러를 관리하기 시작하면서 자기 기본값(localhost.localdomain)으로 덮어써졌다. bluetoothd가 관리하는 컨트롤러는 이름도 bluetoothctl로 설정해야 유지된다:

bluetoothctl select <MAC>
bluetoothctl system-alias "원하는이름"

5. Windows와 정식 페어링

bluetoothctl이 정상화되니 에이전트도 살아났다.

bluetoothctl
agent on
default-agent
pairable on
discoverable on

이전엔 Windows에서 PIN 확인 요청이 뜨는데 보드 쪽에서 응답할 주체(에이전트)가 없어서 막혔었는데, 이번엔 Confirm passkey ... (yes/no) 프롬프트가 정상적으로 뜨고 yes 입력으로 페어링 완료. 결국 PIN 확인 문제도 같은 근본 원인(bluetoothd-mgmt 연동 문제)이었던 것으로 확인.

6. 실제 데이터(문자열) 통신 시도 — 진행 중

페어링 이후 RFCOMM으로 실제 시리얼 데이터를 주고받는 단계.

보드 쪽 SPP 서비스 등록

sdptool add --channel=1 SP
rfcomm listen /dev/rfcomm0 1 &

막힌 지점: Windows에서 COM 포트가 안 보이는 문제 발생. 원인으로 추정되는 것은 SPP 서비스를 등록하기 전에 이미 페어링이 끝나서 Windows가 서비스 목록을 오래된 것으로 캐싱했을 가능성. 해결 시도: Windows에서 장치 제거 → 서비스 재등록 확인 → 재검색/재페어링.

한편 /dev/rfcomm0, /dev/rfcomm1 두 개의 장치 파일이 실제로 생성된 걸 확인했는데(연결 시도 흔적), 정확히 Windows의 어느 COM 포트와 매칭되는지는 rfcomm show 0/rfcomm show 1로 상대 MAC을 대조하거나, 각 포트에 직접 문자열을 보내보며(echo "TEST-0" > /dev/rfcomm0) 경험적으로 확인하는 방식으로 좁혀가는 중.

현재 상태 요약

  • 온보드(hci0)/USB(hci1) 블루투스 하드웨어 인식 및 스캔 테스트 성공
  • bluetoothctl이 컨트롤러를 못 찾는 문제 진단 및 해결 (bluetoothd 재시작)
  • Windows와 정식 페어링(PIN 확인 포함) 성공
  • RFCOMM/SPP를 통한 실제 문자열 양방향 통신 — COM 포트 매칭 확인 중

hciconfig(레거시)와 bluetoothctl(BlueZ 5.x, mgmt 기반)은 서로 다른 경로로 어댑터를 본다는 걸 이번에 제대로 체감했다. 하나가 정상으로 보여도 다른 하나는 아무것도 못 볼 수 있다는 점, 그리고 btmgmt info처럼 커널 mgmt 계층을 직접 조회하는 도구가 원인 분리에 결정적이었다는 점이 이번 트러블슈팅의 핵심 교훈이었다.

댓글남기기

참고