Bluetooth 커널 서브시스템 심화

Linux Bluetooth는 net/bluetooth/ 코어와 BlueZ 사용자 공간 도구가 결합되어 동작합니다. 이 문서는 커널 내부 데이터 경로, 드라이버 계층, 보안, 성능, 디버깅 관점에서 Bluetooth Classic과 BLE를 함께 정리합니다. Bluetooth Core Specification 5.4 기준으로 프로토콜 스택 전반, Mesh, LE Audio까지 포괄합니다.

Bluetooth 프로토콜 스택 아키텍처

Bluetooth Core Specification 구조

Bluetooth Core Specification은 Host와 Controller를 명확히 분리합니다. Controller는 무선 송수신(Radio), 베이스밴드(Baseband), 링크 매니저(Link Manager)를 담당하며, Host는 L2CAP, SDP, RFCOMM, GATT 등 상위 프로토콜을 처리합니다. 이 둘 사이의 표준 인터페이스가 HCI(Host Controller Interface)입니다.

HCI Transport 계층

HCI 패킷은 물리적으로 다양한 전송 수단을 통해 이동합니다. 리눅스 커널은 다음 HCI Transport를 지원합니다:

BlueZ 커널 모듈 구조

리눅스 커널의 Bluetooth 구현은 net/bluetooth/ 디렉토리에 모듈화되어 있습니다. 각 모듈은 독립적으로 빌드 가능하며 CONFIG_BT_* 옵션으로 제어됩니다.

HCI (Host Controller Interface) 심화

HCI 패킷 형식

HCI는 네 가지 패킷 타입을 정의합니다. 각 패킷은 첫 번째 바이트(패킷 인디케이터)로 타입을 구분하며, 이후 타입별 헤더와 페이로드가 따릅니다.

hci_dev 구조체

struct hci_dev는 커널에서 하나의 Bluetooth 어댑터를 나타내는 핵심 자료구조입니다. net/bluetooth/hci_core.c에서 관리하며, 드라이버가 hci_alloc_dev()로 할당하고 hci_register_dev()로 등록합니다.

/* include/net/bluetooth/hci_core.h (주요 필드 발췌) */
struct hci_dev {
    struct list_head list;         /* 전역 hci_dev_list 링크 */
    struct mutex     lock;

    char            name[8];      /* "hci0", "hci1" ... */
    __u16           id;
    __u8            bus;           /* HCI_USB, HCI_UART, HCI_SDIO ... */
    __u8            dev_type;      /* HCI_PRIMARY, HCI_AMP */

    unsigned long   flags;         /* HCI_UP, HCI_RUNNING, HCI_PAIRABLE ... */
    __u8            dev_flags;
    __u16           manufacturer;  /* 벤더 식별자 */
    __u16           lmp_subver;

    /* 드라이버 콜백 */
    int             (*open)(struct hci_dev *hdev);
    int             (*close)(struct hci_dev *hdev);
    int             (*send)(struct hci_dev *hdev, struct sk_buff *skb);
    int             (*setup)(struct hci_dev *hdev);
    int             (*set_bdaddr)(struct hci_dev *hdev, const bdaddr_t *bdaddr);

    /* ACL/SCO 연결 목록 */
    struct list_head conn_hash;
    struct list_head adv_instances;

    /* 명령/이벤트 큐 */
    struct sk_buff_head cmd_q;
    struct sk_buff_head raw_q;
    struct sk_buff      *sent_cmd;

    struct workqueue_struct *workqueue;
    struct workqueue_struct *req_workqueue;
};

HCI 코어 흐름과 상태 머신

HCI 명령은 hci_send_cmd()를 통해 cmd_q에 대기열에 추가된 뒤, hci_cmd_work() 워커가 하나씩 꺼내 드라이버의 send() 콜백으로 전송합니다. 컨트롤러 응답은 Command Complete/Command Status 이벤트로 돌아오며, hci_event_packet()에서 처리됩니다.

/* net/bluetooth/hci_core.c - RX 경로 흐름 요약 */
int hci_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
    switch (hci_skb_pkt_type(skb)) {
    case HCI_EVENT_PKT:
        return hci_event_packet(hdev, skb);
    case HCI_ACLDATA_PKT:
        return hci_acldata_packet(hdev, skb);
    case HCI_SCODATA_PKT:
        return hci_scodata_packet(hdev, skb);
    case HCI_ISODATA_PKT:
        return hci_isodata_packet(hdev, skb);
    }
    return -EINVAL;
}

HCI 장치의 상태 전이는 hdev->flags 비트 필드로 관리됩니다. 주요 상태 전이는 다음과 같습니다:

L2CAP (Logical Link Control and Adaptation Protocol)

채널 멀티플렉싱

L2CAP는 하나의 ACL 링크 위에 여러 논리 채널을 다중화합니다. 각 채널은 CID(Channel Identifier)로 구분되며, 고정 CID(0x0001~0x003F)와 동적 CID(0x0040~)로 나뉩니다. 동적 채널은 PSM(Protocol/Service Multiplexer) 값으로 상위 프로토콜을 식별합니다.

PSM (Protocol/Service Multiplexer)

MTU 협상과 모드

L2CAP 채널 설정 시 양쪽이 MTU(Maximum Transmission Unit)를 협상합니다. 기본 MTU는 BR/EDR에서 672 바이트, LE에서 23 바이트입니다. 실제 대부분의 구현은 더 큰 MTU를 요청합니다.

L2CAP는 여러 전송 모드를 지원합니다:

/* net/bluetooth/l2cap_core.c - L2CAP 연결 요청 처리 핵심 흐름 */
static struct l2cap_chan *l2cap_connect(
    struct l2cap_conn *conn,
    struct l2cap_cmd_hdr *cmd,
    u8 *data, u8 cmd_len)
{
    struct l2cap_conn_req *req = (struct l2cap_conn_req *)data;
    __le16 psm = req->psm;
    __le16 scid = req->scid;

    /* PSM으로 상위 프로토콜 핸들러를 검색 */
    struct l2cap_chan *pchan = l2cap_global_chan_by_psm(
        0, psm, &conn->hcon->src,
        &conn->hcon->dst, ACL_LINK);
    /* 채널 설정: MTU, 모드, 보안 레벨 협상 진행 */
    ...
}

RFCOMM

RS-232 에뮬레이션

RFCOMM은 L2CAP 위에서 RS-232 직렬 포트를 에뮬레이션하는 프로토콜입니다. GSM 07.10 멀티플렉서 프로토콜을 기반으로 하며, 하나의 L2CAP 채널(PSM 0x0003) 위에 최대 30개의 DLC(Data Link Connection)를 다중화할 수 있습니다. 각 DLC는 서버 채널 번호(1~30)로 식별됩니다.

rfcomm_tty 드라이버

커널의 rfcomm 모듈은 TTY 인터페이스(/dev/rfcomm0 등)를 제공합니다. 이를 통해 기존 직렬 포트 프로그램이 수정 없이 Bluetooth 통신에 사용될 수 있습니다.

/* net/bluetooth/rfcomm/tty.c - RFCOMM TTY 드라이버 등록 */
static const struct tty_operations rfcomm_ops = {
    .open           = rfcomm_tty_open,
    .close          = rfcomm_tty_close,
    .write          = rfcomm_tty_write,
    .write_room     = rfcomm_tty_write_room,
    .set_termios    = rfcomm_tty_set_termios,
    .tiocmget       = rfcomm_tty_tiocmget,
    .tiocmset       = rfcomm_tty_tiocmset,
};

/* RFCOMM TTY 생성 명령 예시 */
/* rfcomm bind /dev/rfcomm0 AA:BB:CC:DD:EE:FF 1 */

BLE (Bluetooth Low Energy)

BLE vs Classic 비교

Bluetooth 4.0에서 도입된 BLE는 Classic BR/EDR과는 완전히 다른 PHY와 프로토콜 스택을 사용합니다. 동일한 2.4 GHz ISM 대역을 사용하지만, 채널 수, 변조 방식, 전력 소모, 데이터 전송 패턴이 크게 다릅니다.

Advertising과 Scanning

BLE 장치 검색의 핵심은 Advertising과 Scanning입니다. 광고자(Advertiser)는 37, 38, 39번 채널에서 주기적으로 광고 패킷을 브로드캐스트하고, 스캐너(Scanner)는 이 채널을 순회하며 패킷을 수집합니다.

Connection Interval과 LE PHY

BLE 연결이 수립되면 Central과 Peripheral은 Connection Interval(7.5 ms ~ 4 s)에 따라 주기적으로 데이터를 교환합니다. Slave Latency는 Peripheral이 건너뛸 수 있는 연결 이벤트 수로, 전력 절감에 핵심적입니다.

Extended Advertising (Bluetooth 5.0+)

기존 Legacy Advertising은 31 바이트 페이로드 제한이 있었습니다. Bluetooth 5.0의 Extended Advertising은 보조 채널(Secondary Advertising Channel)을 활용하여 최대 255 바이트(체인 시 더 큰 데이터)의 광고 데이터를 전송할 수 있습니다. 또한 Advertising Sets를 통해 여러 광고 인스턴스를 동시에 운영할 수 있습니다.

GATT/GAP

GAP (Generic Access Profile)

GAP는 Bluetooth 장치의 검색 가능성, 연결 모드, 보안 요구사항을 정의합니다. BLE에서 GAP 역할은 다음 네 가지로 나뉩니다:

GATT (Generic Attribute Profile)

GATT는 BLE 데이터 교환의 핵심 프레임워크입니다. ATT(Attribute Protocol) 위에서 동작하며, 데이터를 Service -> Characteristic -> Descriptor 계층으로 구조화합니다. L2CAP 고정 CID 0x0004를 사용합니다.

GATT 데이터 계층

ATT 프로토콜 주요 연산

SMP (Security Manager Protocol)

페어링 절차 개요

SMP는 BLE 연결의 보안을 담당하며, L2CAP 고정 CID 0x0006에서 동작합니다. 페어링 과정은 크게 세 단계로 진행됩니다:

1. Phase 1 - Pairing Feature Exchange: 양쪽 장치가 IO Capability, 인증 요구사항, 지원 기능을 교환합니다.
2. Phase 2 - Authentication (STK/LTK 생성): 선택된 페어링 방식에 따라 키를 생성합니다. Legacy Pairing은 STK(Short Term Key), LE Secure Connections는 LTK를 직접 생성합니다.
3. Phase 3 - Key Distribution: LTK, IRK(Identity Resolving Key), CSRK(Connection Signature Resolving Key)를 교환합니다.

페어링 방식 비교

LE Secure Connections

Bluetooth 4.2에서 도입된 LE Secure Connections는 ECDH(Elliptic Curve Diffie-Hellman) P-256 키 교환을 사용합니다. Legacy Pairing의 STK 방식보다 훨씬 강력한 보안을 제공하며, 패시브 도청에 대한 방어력이 있습니다. 커널에서는 net/bluetooth/smp.c의 sc_send_public_key()에서 ECDH 공개키를 교환합니다.

키 분배

/* net/bluetooth/smp.c - SMP 페어링 요청 처리 */
static u8 smp_cmd_pairing_req(struct l2cap_conn *conn,
                              struct sk_buff *skb)
{
    struct smp_cmd_pairing *req = (void *)skb->data;
    struct smp_chan *smp;

    /* IO Capability와 인증 요구사항 확인 */
    smp->preq[0] = SMP_CMD_PAIRING_REQ;
    memcpy(&smp->preq[1], req, sizeof(*req));

    /* SC 지원 여부에 따라 Legacy/SC 분기 */
    if (req->auth_req & SMP_AUTH_SC)
        set_bit(SMP_FLAG_SC, &smp->flags);

    /* 페어링 방식 결정: IO Capability 매트릭스 참조 */
    smp->method = get_auth_method(smp, req->io_capability,
                                  rsp->io_capability);
    ...
}

A2DP와 LE Audio

A2DP 오디오 프로파일

A2DP(Advanced Audio Distribution Profile)는 Classic Bluetooth에서 고품질 스테레오 오디오 스트리밍에 사용됩니다. AVDTP(Audio/Video Distribution Transport Protocol) 위에서 동작하며, L2CAP의 Streaming Mode를 사용하여 재전송 없이 실시간 전송을 우선합니다.

A2DP 코덱 비교

LE Audio와 ISO Channels

Bluetooth 5.2에서 도입된 LE Audio는 BLE 기반의 차세대 오디오 표준입니다. 기존 A2DP의 Classic Bluetooth 의존성을 제거하고, 저전력과 새로운 기능을 제공합니다.

LC3 코덱과 Broadcast Audio

LC3(Low Complexity Communication Codec)는 LE Audio의 필수 코덱으로, SBC보다 절반의 비트레이트에서 동등 이상의 품질을 제공합니다. Broadcast Audio (Auracast)는 BIS(Broadcast ISO Stream)를 통해 하나의 소스에서 다수의 수신기로 오디오를 동시 전송하는 기능입니다.

커널에서 ISO 채널은 HCI ISO Data 패킷(타입 0x05)을 통해 전송되며, net/bluetooth/iso.c에서 소켓 인터페이스를 제공합니다.

/* net/bluetooth/iso.c - ISO 소켓 생성 */
static int iso_sock_create(struct net *net,
                          struct socket *sock, int protocol,
                          int kern)
{
    struct sock *sk;

    sock->ops = &iso_sock_ops;
    sk = iso_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern);
    if (!sk)
        return -ENOMEM;

    iso_sock_init(sk, NULL);
    return 0;
}

Bluetooth Mesh

Mesh 네트워크 토폴로지

Bluetooth Mesh는 BLE Advertising/Scanning 기반의 관리형 플러딩(Managed Flooding) 메시 네트워크입니다. 기존 BLE의 포인트 투 포인트 토폴로지를 넘어 수백~수천 노드의 대규모 네트워크를 구성할 수 있습니다. 메시지는 TTL(Time To Live) 기반으로 네트워크 전체에 전파됩니다.

노드 역할

Provisioning

Provisioning은 새로운 장치를 Mesh 네트워크에 추가하는 과정입니다. Provisioner가 인증 후 NetKey, IV Index, Unicast Address를 할당합니다. 이 과정은 PB-ADV(Advertising Bearer) 또는 PB-GATT(GATT Bearer)를 통해 수행됩니다.

메시지 전달 과정

1. Application Layer: 모델(Model)이 메시지를 생성하고 AppKey로 암호화
2. Upper Transport: 접근 메시지(Access Message)를 세그먼트화하고 Application/Device Key로 암호화/인증
3. Lower Transport: 세그먼트 조립/분해, SAR(Segmentation and Reassembly) 처리
4. Network Layer: NetKey로 암호화/인증, TTL 관리, 릴레이 결정
5. Bearer Layer: BLE Advertising 패킷으로 변환하여 전송

BlueZ 아키텍처

bluetoothd 데몬

bluetoothd는 BlueZ의 핵심 데몬으로, D-Bus를 통해 응용 프로그램에 Bluetooth 기능을 노출합니다. GATT 프로파일, 에이전트 기반 페어링, 장치 관리 등 대부분의 상위 로직을 담당합니다.

D-Bus API 구조

mgmt API (커널-유저 인터페이스)

mgmt API는 bluetoothd가 커널 Bluetooth 스택을 제어하는 전용 인터페이스입니다. 기존의 hciconfig/hcitool이 사용하던 raw HCI 소켓 방식을 대체합니다. AF_BLUETOOTH 소켓의 BTPROTO_HCI에서 HCI_CHANNEL_CONTROL로 접근합니다.

/* mgmt 소켓 생성 (사용자 공간) */
int fd = socket(AF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC,
                BTPROTO_HCI);

struct sockaddr_hci addr = {
    .hci_family  = AF_BLUETOOTH,
    .hci_dev     = HCI_DEV_NONE,
    .hci_channel = HCI_CHANNEL_CONTROL,  /* mgmt 채널 */
};
bind(fd, (struct sockaddr *)&addr, sizeof(addr));

주요 mgmt 명령

# btmgmt로 mgmt 명령 직접 실행
btmgmt info               # 어댑터 정보 확인
btmgmt power on            # 전원 켜기
btmgmt find                # 장치 검색
btmgmt advertising on      # LE 광고 활성화
btmgmt bondable on         # 페어링 허용

커널 드라이버

btusb

btusb는 가장 널리 사용되는 Bluetooth HCI 드라이버입니다. USB 인터페이스를 통해 HCI 패킷을 송수신하며, 다양한 벤더의 USB Bluetooth 어댑터를 지원합니다.

/* drivers/bluetooth/btusb.c - 핵심 구조 */
static int btusb_probe(struct usb_interface *intf,
                      const struct usb_device_id *id)
{
    struct btusb_data *data;
    struct hci_dev *hdev;

    data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL);
    hdev = hci_alloc_dev();

    hdev->bus   = HCI_USB;
    hdev->open  = btusb_open;     /* URB 제출 시작 */
    hdev->close = btusb_close;    /* URB 취소 */
    hdev->send  = btusb_send_frame; /* TX: 패킷 타입별 엔드포인트 선택 */
    hdev->flush = btusb_flush;

    /* 벤더별 초기화 콜백 설정 */
    if (id->driver_info & BTUSB_INTEL_NEW)
        hdev->setup = btintel_setup_combined;
    else if (id->driver_info & BTUSB_REALTEK)
        hdev->setup = btrtl_setup_realtek;
    else if (id->driver_info & BTUSB_MEDIATEK)
        hdev->setup = btmtk_usb_setup;

    return hci_register_dev(hdev);
}

USB 엔드포인트 사용

hci_uart (UART HCI 드라이버)

hci_uart는 UART 기반 Bluetooth 칩과 통신하는 프레임워크 드라이버입니다. 여러 프로토콜 변형을 플러그인 방식으로 지원합니다:

벤더별 초기화 드라이버

구성 요소와 계층

커널 Bluetooth는 크게 컨트롤러 I/O 계층(HCI 드라이버), 프로토콜 계층(L2CAP/RFCOMM/SCO), 소켓 계층(AF_BLUETOOTH), 정책/관리 계층(mgmt)으로 나뉩니다. 아래 다이어그램은 패킷이 하드웨어에서 사용자 공간까지 이동하는 전체 경로를 보여줍니다.

AF_BLUETOOTH 소켓 패밀리

리눅스 커널은 AF_BLUETOOTH 주소 패밀리를 통해 사용자 공간에 Bluetooth 소켓 인터페이스를 제공합니다. 프로토콜 번호에 따라 다양한 소켓 타입을 사용할 수 있습니다:

보안 모델: SSP와 SMP

Classic은 SSP(Secure Simple Pairing), BLE는 SMP(Security Manager Protocol)를 중심으로 링크 키/LTK를 교환합니다. 보안 레벨은 페어링 방식(Just Works, Passkey, Numeric Comparison)에 따라 달라집니다.

보안 레벨 정의

페어링 방식별 특징

Cross-Transport Key Derivation

Bluetooth 4.2+에서는 한 번의 페어링으로 Classic과 BLE 양쪽 키를 동시에 생성할 수 있습니다. 이를 Cross-Transport Key Derivation(CTKD)이라 합니다. Classic에서 페어링한 키를 BLE LTK로 변환하거나, 그 반대도 가능합니다. 이 과정은 L2CAP CID 0x0007(BR/EDR SMP 채널)을 통해 수행됩니다.

드라이버 모델: btusb와 hci_uart

btusb는 USB 인터럽트/벌크 엔드포인트를 통해 HCI 패킷을 수집하고, hci_uart는 H4/H5 프로토콜로 UART 컨트롤러와 통신합니다.

btusb 프로브 흐름

/* drivers/bluetooth/btusb.c 프로브 패턴 요약 */
static int btusb_probe(struct usb_interface *intf,
                      const struct usb_device_id *id)
{
    struct hci_dev *hdev = hci_alloc_dev();
    if (!hdev)
        return -ENOMEM;

    hdev->bus = HCI_USB;
    hdev->open  = btusb_open;
    hdev->close = btusb_close;
    hdev->send  = btusb_send_frame;

    /* btusb_send_frame()은 패킷 타입에 따라
       Control(Command), Bulk(ACL), Isoc(SCO) 엔드포인트를 선택 */

    return hci_register_dev(hdev);
}

hci_uart 초기화 흐름

/* drivers/bluetooth/hci_ldisc.c - Line Discipline 기반 초기화 */
static int hci_uart_tty_open(struct tty_struct *tty)
{
    struct hci_uart *hu;

    hu = kzalloc(sizeof(struct hci_uart), GFP_KERNEL);
    hu->tty = tty;
    tty->disc_data = hu;

    /* 이후 HCIUARTSETPROTO ioctl로 프로토콜(H4/H5/QCA 등) 설정
       hdev = hci_alloc_dev() -> hci_register_dev() */
    return 0;
}

/* serdev 기반 초기화 (최신 커널 권장) */
static int hci_uart_probe(struct serdev_device *serdev)
{
    /* Device Tree 또는 ACPI 매칭으로 자동 프로브
       별도의 userspace 설정(hciattach) 불필요 */
}

성능 튜닝 포인트

연결 파라미터 최적화

• 스캔 윈도우/인터벌 조정으로 연결 지연과 전력 사용량 균형 맞추기
• LE Connection Interval과 Slave Latency 튜닝으로 배터리 수명 최적화
• 오디오 경로에서 SCO/eSCO 패킷 손실이 증가하면 USB autosuspend 설정 점검
• 고밀도 환경에서는 AFH(Adaptive Frequency Hopping) 동작과 채널 혼잡도를 함께 관찰

LE Connection Parameter 가이드라인

USB autosuspend 설정

# Bluetooth USB 어댑터의 autosuspend 비활성화 (오디오 끊김 방지)
echo -1 > /sys/bus/usb/devices/1-3/power/autosuspend_delay_ms

# 또는 udev 규칙으로 영구 설정
# /etc/udev/rules.d/99-bluetooth-power.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="0a2b", \
  ATTR{power/autosuspend_delay_ms}="-1"

디버깅과 성능 분석

btmon: 핵심 디버깅 도구

btmon은 HCI와 mgmt 트래픽을 실시간으로 모니터링하는 BlueZ의 핵심 도구입니다. 커널의 HCI 모니터 채널(HCI_CHANNEL_MONITOR)을 통해 패킷을 수집합니다.

# 실시간 HCI + mgmt 트래픽 모니터링
sudo btmon

# 파일로 저장 (BT Snoop 형식, Wireshark에서 열기 가능)
sudo btmon --write /tmp/bluetooth.log

# 특정 어댑터만 모니터링
sudo btmon --index 0

# 타임스탬프와 함께 출력
sudo btmon --date

bluetoothctl 디버깅

# 어댑터 상태 확인
bluetoothctl show

# 장치 검색
bluetoothctl scan on

# 연결된 장치 목록
bluetoothctl devices Connected

# 장치 정보 상세 확인
bluetoothctl info AA:BB:CC:DD:EE:FF

# GATT 서비스 탐색
bluetoothctl menu gatt
bluetoothctl list-attributes

debugfs 인터페이스

커널은 /sys/kernel/debug/bluetooth/에 디버깅 정보를 노출합니다.

# HCI 장치별 디버그 정보
ls /sys/kernel/debug/bluetooth/hci0/

# 주요 파일:
# features       - 지원 기능 비트맵
# manufacturer   - 벤더 정보
# hci_revision   - HCI 리비전
# blacklist      - 장치 블랙리스트
# uuids          - 등록된 서비스 UUID 목록
# conn_info_min/max_age - 연결 정보 캐시 수명

cat /sys/kernel/debug/bluetooth/hci0/features

커널 로그 분석

# Bluetooth 관련 커널 로그 필터링
dmesg | grep -i -E "bluetooth|hci|l2cap|smp|btusb|rfcomm"

# 동적 디버그 활성화 (상세 추적)
echo "module bluetooth +p" > /sys/kernel/debug/dynamic_debug/control
echo "module btusb +p" > /sys/kernel/debug/dynamic_debug/control

# BT Snoop 로그를 Wireshark로 분석
sudo btmon --write /tmp/bt_snoop.log
# Wireshark에서 File -> Open으로 /tmp/bt_snoop.log 열기

일반적인 문제와 해결

커널 설정

필수 사용자 공간 패키지

참고자료

• 커널 공식 문서: Bluetooth
• 커널 소스: net/bluetooth
• 커널 소스: drivers/bluetooth
• BlueZ 프로젝트
• Bluetooth SIG: Core Specification
• Bluetooth SIG: LE Audio Specification
• Bluetooth SIG: Mesh Specification