Bluetooth 커널 서브시스템

Linux Bluetooth는 net/bluetooth/ 코어와 BlueZ 사용자 공간(User Space) 도구가 결합되어 동작합니다. 이 문서는 커널 내부 데이터 경로, 드라이버 계층, 보안, 성능, 디버깅(Debugging) 관점에서 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 커널 모듈(Kernel Module) 구조

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

HCI (Host Controller Interface)

HCI 패킷 형식

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

hci_dev 구조체(Struct)

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() 콜백(Callback)으로 전송합니다. 컨트롤러 응답은 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 비트 필드로 관리됩니다. 주요 상태 전이는 다음과 같습니다:

Bluetooth Classic 연결 수립 흐름

Bluetooth Classic(BR/EDR)에서 두 장치가 연결을 수립하는 과정은 Inquiry, Paging, 연결 설정, 인증의 4단계로 진행됩니다. 각 단계에서 HCI 명령과 이벤트가 호스트와 컨트롤러 사이를 오가며, 최종적으로 ACL 링크가 생성됩니다.

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)

다음 다이어그램은 하나의 ACL 링크 위에서 여러 L2CAP 채널이 CID와 PSM을 통해 다중화되는 구조를 보여줍니다. 고정 채널(ATT, SMP, 시그널링)과 동적 채널(RFCOMM, A2DP 등)이 동시에 공존하며, 각 채널은 독립적인 MTU와 전송 모드를 가집니다.

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 직렬 포트(Serial Port)를 에뮬레이션하는 프로토콜입니다. 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 프로브(Probe) 흐름

/* 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 열기

일반적인 문제와 해결

커널 설정

필수 사용자 공간 패키지

HCI 패킷 구조와 커널 처리 경로

HCI Command 패킷 상세

HCI Command 패킷은 호스트에서 컨트롤러로 전송되는 제어 명령입니다. OpCode는 OGF(Opcode Group Field, 6비트)와 OCF(Opcode Command Field, 10비트)로 구성됩니다. 커널에서는 hci_send_cmd()로 명령을 큐에 넣고, hci_cmd_work() 워커가 순차 전송합니다.

ACL Data 패킷 구조

ACL 데이터 패킷은 비동기 데이터 전송에 사용됩니다. 헤더의 Handle 필드에는 연결 핸들(12비트)과 패킷 경계 플래그(PB Flag, 2비트), 브로드캐스트 플래그(BC Flag, 2비트)가 포함됩니다. PB 플래그로 L2CAP PDU의 첫 번째 조각인지 연속 조각인지를 구분합니다.

/* include/net/bluetooth/hci.h - ACL 헤더 구조 */
struct hci_acl_hdr {
    __le16  handle;     /* 12비트 handle + 2비트 PB + 2비트 BC */
    __le16  dlen;       /* 데이터 길이 */
} __packed;

#define ACL_START_NO_FLUSH   0x00
#define ACL_CONT             0x01
#define ACL_START            0x02
#define ACL_COMPLETE         0x03

/* PB 플래그 추출 매크로 */
#define hci_handle_pack(h, f)  ((__u16) ((h) | ((f) << 12)))
#define hci_handle(h)          ((h) & 0x0FFF)
#define hci_flags(h)           ((h) >> 12)

btusb에서 hci_core, L2CAP까지의 RX 경로

USB Bluetooth 어댑터에서 수신된 HCI 패킷이 L2CAP 프로토콜 핸들러(Handler)에 도달하기까지의 전체 경로를 추적합니다. 이 흐름을 이해하면 패킷 손실이나 지연의 원인을 정확히 진단할 수 있습니다.

/* net/bluetooth/hci_core.c - ACL 데이터 수신 처리 */
static void hci_acldata_packet(struct hci_dev *hdev,
                               struct sk_buff *skb)
{
    struct hci_acl_hdr *hdr = (void *)skb->data;
    struct hci_conn *conn;
    __u16 handle = __le16_to_cpu(hdr->handle);
    __u16 flags  = hci_flags(handle);

    handle = hci_handle(handle);
    conn = hci_conn_hash_lookup_handle(hdev, handle);
    if (!conn) {
        bt_dev_err(hdev, "ACL packet for unknown handle %d", handle);
        kfree_skb(skb);
        return;
    }

    skb_pull(skb, HCI_ACL_HDR_SIZE);
    /* L2CAP로 전달 - PB 플래그에 따라 재조립 수행 */
    l2cap_recv_acldata(conn, skb, flags);
}

TX 경로: L2CAP에서 btusb까지

송신 경로는 수신의 역순으로 진행됩니다. l2cap_do_send()가 L2CAP PDU를 생성하고, hci_send_acl()이 ACL 프래그먼트로 분할한 뒤 hci_tx_work() 워커가 드라이버의 send() 콜백을 호출합니다. 컨트롤러의 버퍼 여유(Num_Completed_Packets 이벤트)를 추적하여 흐름 제어를 수행합니다.

/* net/bluetooth/hci_core.c - ACL TX 흐름 제어 */
static struct hci_conn *hci_low_sent(
    struct hci_dev *hdev, __u8 type, int *quote)
{
    /* 연결 간 공정 스케줄링: 가장 적게 보낸 연결을 선택 */
    /* cnt = hdev->acl_cnt (컨트롤러 여유 버퍼 수) */
    /* *quote = cnt / num_connections (연결당 할당량) */
    ...
}

BLE GATT 프로파일 구현과 커널 경로

ATT 패킷 처리 커널 경로

ATT 프로토콜 패킷은 L2CAP 고정 CID 0x0004를 통해 전달됩니다. 커널에서의 처리 경로는 다음과 같습니다:

1. l2cap_recv_acldata()에서 CID 0x0004 확인
2. l2cap_recv_frame() -> l2cap_data_channel()
3. ATT 고정 채널의 recv() 콜백 호출
4. 커널은 기본적인 ATT 라우팅(Routing)만 수행하고, 실제 GATT 로직은 BlueZ bluetoothd가 처리

/* net/bluetooth/l2cap_core.c - ATT 고정 채널 등록 */
static struct l2cap_chan *l2cap_le_connect(struct l2cap_conn *conn)
{
    struct l2cap_chan *chan;

    /* ATT 고정 채널 (CID 0x0004) 검색 */
    chan = l2cap_global_fixed_chan(conn, L2CAP_CID_ATT,
                                  &conn->hcon->src);
    if (!chan)
        return NULL;

    /* 채널 상태를 CONNECTED로 전환 */
    l2cap_chan_add(conn, chan);
    l2cap_chan_ready(chan);
    return chan;
}

GATT 서비스 UUID 체계

Bluetooth SIG가 할당한 표준 16비트 UUID는 Base UUID(00000000-0000-1000-8000-00805F9B34FB)의 상위 32비트 중 16비트를 대체하여 128비트로 확장됩니다. 커스텀 서비스는 128비트 UUID를 사용합니다.

GATT Notification/Indication 메커니즘

GATT 서버가 클라이언트에게 데이터 변경을 능동적으로 알리는 두 가지 방법이 있습니다. Notification은 확인 응답 없이 전송하고, Indication은 확인을 받아야 다음 전송이 가능합니다. 두 방법 모두 CCCD(Client Characteristic Configuration Descriptor, UUID 0x2902)에 클라이언트가 구독 비트를 기록해야 활성화됩니다.

/* BlueZ bluetoothd - GATT Notification 전송 예시 (D-Bus 기반) */
/* bluetoothctl에서 Characteristic에 대해: */
# select-attribute /org/bluez/hci0/dev_.../service000a/char000b
# notify on     <-- CCCD에 0x0001 기록 (Notification 활성화)
# notify off    <-- CCCD에 0x0000 기록 (비활성화)

Bluetooth 5.x 신기능

Bluetooth 5.0 주요 기능

Bluetooth 5.1 - Direction Finding

Bluetooth 5.1은 AoA(Angle of Arrival)와 AoD(Angle of Departure) 기술로 방향 탐지 기능을 도입했습니다. CTE(Constant Tone Extension)를 BLE 패킷에 부착하여 안테나 배열로 신호 방향을 측정합니다. 실내 위치 추적(IPS, Indoor Positioning System)의 핵심 기술입니다.

Bluetooth 5.2 - LE Audio / EATT / Power Control

Bluetooth 5.2는 LE Audio의 기반 기술을 도입한 핵심 버전입니다:

• ISO Channels (CIS/BIS): 등시성 데이터 전송. CIS는 연결 기반, BIS는 브로드캐스트 기반
• LC3 코덱: SBC 대비 동등 품질에서 50% 낮은 비트레이트
• EATT (Enhanced ATT): L2CAP Enhanced Credit-based Flow Control로 여러 ATT 베어러 동시 사용
• LE Power Control: RSSI 기반 송신 전력 동적 조정

Bluetooth 5.3 - AdvDataInfo / Channel Classification / Encryption Key Size

• AdvDataInfo (ADI) in Periodic Advertising: 중복 수신 방지로 전력 절감
• Channel Classification Enhancement: 서브이벤트별 채널 품질 보고
• Connection Subrating: 연결 이벤트 하위 등급으로 전력 최적화
• LE Enhanced Connection Complete v2: 확장된 연결 완료 이벤트

Bluetooth 5.4 - PAwR / eSL / Encrypted Advertising Data

• PAwR (Periodic Advertising with Responses): 주기적 광고에 대한 응답 기능, ESL(Electronic Shelf Labels) 핵심 기술
• Encrypted Advertising Data: 광고 데이터 암호화로 프라이버시 강화
• LE GATT Security Levels Characteristic: GATT 서비스별 보안 수준 광고

Channel Sounding (Bluetooth 6.0)

Bluetooth 6.0에서 도입된 Channel Sounding은 센티미터 수준의 정밀 거리 측정 기술입니다. 기존 RSSI 기반 근접 감지의 한계를 극복하며, Phase-Based Ranging과 Round-Trip Time(RTT) 방식을 결합합니다. 디지털 키(자동차 잠금(Lock) 해제), 물리적 근접 검증, 실내 위치 추적에 핵심적입니다. 리눅스 커널에서의 지원은 6.x 이후 버전에서 HCI 명령/이벤트 추가로 진행 중입니다.

커널 소스 구조 (net/bluetooth/ 맵)

net/bluetooth/ 디렉토리 구조

Bluetooth 코어 프로토콜 스택의 소스 코드는 net/bluetooth/ 디렉토리에 위치합니다. 각 파일의 역할과 상호 의존 관계를 이해하면 커널 디버깅과 패치 작성이 수월해집니다.

drivers/bluetooth/ 디렉토리 구조

btmon/hcidump 디버깅

btmon 고급 사용법

btmon은 커널의 HCI_CHANNEL_MONITOR를 사용하여 모든 HCI 및 mgmt 트래픽을 사용자 공간에서 캡처합니다. Wireshark의 BT Snoop 형식과 호환되며, 원격 장비에서 캡처한 로그를 워크스테이션에서 분석할 수 있습니다.

# 상세 타임스탬프 + 특정 어댑터 모니터링
sudo btmon --index 0 --date --time

# BT Snoop 형식으로 저장 (Wireshark에서 분석용)
sudo btmon --write /tmp/bt_trace.snoop

# 기존 스눕 파일 읽기 (오프라인 분석)
btmon --read /tmp/bt_trace.snoop

# 실시간 + 파일 저장 동시 수행
sudo btmon --write /tmp/bt_trace.snoop 2>&1 | tee /tmp/bt_console.log

# Priority 기반 필터 (priority는 btmon 자체는 미지원, 대안:)
# Wireshark에서 btmon 파일을 열고 Display Filter 적용
# 예: bthci_evt.code == 0x0e (Command Complete)

hcidump (레거시 도구)

hcidump는 btmon 이전에 사용되던 레거시 캡처 도구입니다. 현재는 btmon 사용을 권장하지만, 일부 환경에서 여전히 유용합니다.

# 전체 패킷 덤프
sudo hcidump -X

# 특정 패킷 타입만 필터링
sudo hcidump -t HCI   # HCI 이벤트/명령만
sudo hcidump -t L2CAP # L2CAP 패킷만
sudo hcidump -t SMP   # SMP 페어링 패킷만

# pcap 형식으로 저장
sudo hcidump -w /tmp/bt.pcap

Wireshark로 Bluetooth 트래픽 분석

btmon의 BT Snoop 출력을 Wireshark에서 열면 프로토콜별 계층 분석이 가능합니다. 주요 Display Filter:

커널 tracing으로 Bluetooth 디버깅

# ftrace로 Bluetooth 함수 추적
echo 'hci_*' > /sys/kernel/debug/tracing/set_ftrace_filter
echo 'l2cap_*' >> /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on

# 추적 결과 확인
cat /sys/kernel/debug/tracing/trace

# Bluetooth tracepoint 이벤트
ls /sys/kernel/debug/tracing/events/bluetooth/
# hci_send_cmd, hci_recv_frame, l2cap_send, l2cap_recv 등

# 특정 tracepoint 활성화
echo 1 > /sys/kernel/debug/tracing/events/bluetooth/hci_recv_frame/enable

Bluetooth/Wi-Fi 공존 메커니즘

간섭 문제

Bluetooth(2.402~2.480 GHz)와 Wi-Fi 2.4 GHz(2.412~2.462 GHz)는 동일한 ISM 대역을 공유합니다. 특히 Wi-Fi 채널 1, 6, 11과 Bluetooth 호핑 채널이 겹칠 수 있으며, 콤보 칩(같은 안테나 공유)에서는 물리적으로 동시 전송이 불가능합니다. 이 문제를 해결하기 위해 여러 공존 메커니즘이 사용됩니다.

공존 메커니즘 비교

커널에서의 공존 설정

# Intel 칩셋: btintel coex 파라미터
# dmesg에서 공존 설정 확인
dmesg | grep -i coex

# iwlwifi + btusb 콤보에서 공존 상태 확인
cat /sys/kernel/debug/iwlwifi/*/bt_coex

# Qualcomm 칩: IBS(In-Band Sleep)와 공존
# Device Tree에서 공존 핀 설정
# bt-coex-pin = <GPIO_NUM>;

# Wi-Fi 채널을 5 GHz로 전환하여 간섭 회피 (가장 효과적)
iw dev wlan0 set channel 36

커널 버전별 Bluetooth 변경 이력

L2CAP ERTM/Streaming 모드

ERTM (Enhanced Retransmission Mode) 상세

ERTM은 L2CAP에 TCP와 유사한 신뢰성을 제공합니다. I-Frame(Information Frame)에 시퀀스 번호 (TxSeq/ReqSeq)를 부여하고, S-Frame(Supervisory Frame)으로 흐름 제어와 재전송을 관리합니다. OBEX 파일 전송이나 AVRCP 같은 신뢰성이 중요한 프로토콜에서 사용됩니다.

ERTM 프레임 타입

/* net/bluetooth/l2cap_core.c - ERTM I-Frame 전송 */
static void l2cap_ertm_send(struct l2cap_chan *chan)
{
    struct sk_buff *skb;

    while (chan->tx_send_head &&
           chan->unacked_frames < chan->remote_tx_win) {
        skb = chan->tx_send_head;

        /* TxSeq/ReqSeq 설정 */
        l2cap_set_txseq(chan, skb);
        chan->next_tx_seq = (chan->next_tx_seq + 1) %
                           chan->tx_win_max;
        chan->unacked_frames++;

        /* 재전송 타이머 시작 */
        l2cap_set_retrans_timer(chan);
        l2cap_do_send(chan, skb);
    }
}

ERTM 타이머(Timer)

Streaming Mode

Streaming Mode는 ERTM과 유사하지만 재전송이 없습니다. 순서 번호로 패킷 누락을 감지하되, 재전송 대신 상위 계층에 누락을 알립니다. A2DP 오디오 스트리밍처럼 약간의 패킷 손실보다 지연이 더 치명적인 경우에 적합합니다.

LE Credit-based Flow Control (LE CoC)

BLE에서 대용량 데이터를 전송할 때 사용하는 모드입니다. 수신 측이 크레딧(Credit)을 발급하고, 송신 측은 크레딧만큼만 SDU를 전송할 수 있습니다. 크레딧이 소진되면 수신 측이 추가 크레딧을 발급할 때까지 대기합니다. GATT의 20바이트 ATT MTU 제한을 우회하여 수백 KB 단위 데이터를 효율적으로 전송할 수 있습니다.

/* net/bluetooth/l2cap_core.c - LE CoC 크레딧 관리 */
static void l2cap_chan_le_send_credits(struct l2cap_chan *chan)
{
    struct l2cap_le_credits pkt;
    u16 return_credits;

    /* 수신 버퍼 여유량에 기반하여 크레딧 발급 */
    return_credits = chan->rx_credits_max - chan->rx_credits;
    if (return_credits < chan->rx_credits_max / 2)
        return;

    pkt.cid     = cpu_to_le16(chan->scid);
    pkt.credits = cpu_to_le16(return_credits);

    chan->rx_credits += return_credits;
    l2cap_send_cmd(chan->conn, chan->ident,
                  L2CAP_LE_CREDITS, sizeof(pkt), &pkt);
}

SMP 페어링 상세

IO Capability 매트릭스

SMP 페어링 방식은 양쪽 장치의 IO Capability 조합에 의해 자동으로 결정됩니다. 다음 매트릭스는 LE Secure Connections 모드에서의 페어링 방식 선택을 보여줍니다:

OOB (Out-of-Band) 페어링

OOB 페어링은 Bluetooth 무선 채널이 아닌 외부 채널(NFC, QR 코드 등)을 통해 인증 데이터를 교환합니다. NFC 탭으로 페어링하는 경우가 대표적입니다. 커널에서는 SMP_CMD_PAIRING_REQ의 OOB 플래그와 mgmt API의 Add Remote OOB Data 명령으로 처리합니다.

/* net/bluetooth/smp.c - OOB 데이터 확인 */
static u8 smp_cmd_pairing_req(struct l2cap_conn *conn,
                              struct sk_buff *skb)
{
    ...
    /* OOB 데이터 가용 여부 확인 */
    if (req->oob_flag == SMP_OOB_PRESENT) {
        /* 로컬에 OOB 데이터가 있으면 사용 */
        if (test_bit(SMP_FLAG_LOCAL_OOB, &smp->flags))
            smp->method = REQ_OOB;
    }
    ...
}

Passkey Entry 내부 동작

Passkey Entry에서는 6자리 숫자(000000~999999)를 20비트로 변환하여 각 비트에 대해 Confirm/Random 교환을 반복합니다(LE SC 모드). 총 20라운드의 교환으로 MITM을 방어합니다. Legacy Pairing에서는 단일 라운드로 처리되어 보안이 약합니다.

Numeric Comparison

Numeric Comparison은 LE Secure Connections에서만 사용됩니다. ECDH 키 교환 후 양쪽이 동일한 6자리 숫자를 계산하여 표시하고, 사용자가 양쪽의 숫자가 같은지 확인하여 Yes/No로 응답합니다. 패시브/능동 MITM 공격 모두에 강력한 방어를 제공합니다.

Address Resolution과 Privacy

BLE Privacy 기능은 Resolvable Private Address(RPA)를 사용하여 장치 추적을 방지합니다. RPA는 IRK(Identity Resolving Key)로 생성/검증되며, 주기적으로 변경됩니다(기본 15분). 커널의 hci_conn.c에서 RPA 해석을 수행하며, 하드웨어 오프로딩(Offloading)이 가능한 칩셋에서는 컨트롤러가 직접 해석합니다.

# Privacy 활성 상태 확인
btmgmt info
# Privacy: enabled (addr-resolution: on, rpa-timeout: 900s)

# RPA timeout 설정 (초 단위, 기본 900초 = 15분)
# /sys/kernel/debug/bluetooth/hci0/rpa_timeout

Bluetooth Mesh 프로비저닝/릴레이

프로비저닝 프로토콜 상세

Mesh 프로비저닝은 비보안 상태의 장치를 안전하게 네트워크에 추가하는 과정입니다. ECDH 키 교환과 인증을 거쳐 NetKey, AppKey, Unicast Address를 배포합니다.

1. Beaconing: 비프로비저닝 장치가 Unprovisioned Device Beacon을 브로드캐스트
2. Invitation: Provisioner가 Provisioning Invite PDU를 전송, 장치가 Capabilities로 응답
3. Public Key Exchange: ECDH P-256 공개키 교환 (OOB 또는 In-Band)
4. Authentication: Output OOB(LED 깜빡임), Input OOB(버튼 누름), Static OOB(QR 코드), No OOB 중 선택
5. Confirmation: 양쪽이 Confirm/Random 값을 교환하여 인증 확인
6. Distribution: Provisioner가 Provisioning Data(NetKey, IV Index, Unicast Address)를 암호화하여 전송

Mesh 보안 계층

Relay 동작 상세

Relay 노드는 수신한 Network PDU를 재전송하여 메시지 도달 범위를 확장합니다. 중복 전송 방지를 위해 Network Message Cache에 최근 메시지의 (SRC, SEQ) 쌍을 저장하고, 이미 처리한 메시지는 폐기합니다. TTL이 0이면 더 이상 릴레이하지 않습니다.

Mesh Relay 결정 로직은 다음과 같은 순서로 동작합니다 (bluetooth-meshd 내부).

1. TTL > 1인지 확인합니다.
2. SRC가 자신이 아닌지 확인합니다.
3. Network Message Cache에 (SRC, SEQ) 쌍이 없는지 확인합니다.
4. 조건 충족 시 TTL-1로 재전송합니다.
5. 캐시에 (SRC, SEQ)를 추가합니다.

Friend/Low Power 노드 상호작용

Low Power(LP) 노드는 대부분의 시간을 슬립 상태로 보내며, Friend 노드가 LP 노드 대신 메시지를 수신/저장합니다. LP 노드는 주기적으로 깨어나 Friend Poll 메시지를 보내 대기 중인 메시지를 수신합니다.

Directed Forwarding (Mesh Protocol 1.1)

Mesh Protocol 1.1에서 도입된 Directed Forwarding은 기존 Managed Flooding 방식의 비효율성을 개선합니다. 경로 탐색(Path Discovery)을 통해 최적 경로를 찾고, 해당 경로의 노드만 메시지를 중계하여 네트워크 트래픽을 크게 줄입니다. 대규모 Mesh 네트워크(수백 노드 이상)에서 특히 효과적입니다.

Bluetooth 에러 코드와 Disconnection Reason

HCI 에러 코드

HCI 이벤트에서 반환되는 에러 코드는 연결 실패, 끊김, 명령 거부의 원인을 진단하는 핵심 정보입니다. btmon에서 확인 가능하며, 커널 로그(dmesg)에도 출력됩니다.

실전 시나리오와 트러블슈팅

시나리오 1: BLE 센서 데이터 수집 게이트웨이

리눅스 장치(Raspberry Pi 등)를 BLE Central로 사용하여 다수의 BLE 센서에서 데이터를 수집하는 산업용 게이트웨이 시나리오입니다.

# 1. 어댑터 상태 확인
btmgmt info
# supported-settings: powered connectable le
# current-settings:  powered le

# 2. LE 스캔 시작 (passive, 중복 허용)
btmgmt find -l        # LE only 스캔

# 3. bluetoothctl로 연결 및 GATT 서비스 탐색
bluetoothctl
# [bluetooth]# scan on
# [bluetooth]# connect AA:BB:CC:DD:EE:FF
# [bluetooth]# menu gatt
# [bluetooth]# list-attributes
# [bluetooth]# select-attribute /org/bluez/hci0/dev_.../service000a/char000b
# [bluetooth]# read
# [bluetooth]# notify on

# 4. 다수 연결 시 파라미터 튜닝
# Connection Interval을 100ms 이상으로 설정하여 다수 연결 안정화
# Supervision Timeout은 10초 이상 권장

시나리오 2: A2DP 오디오 끊김 해결

# 1. btmon으로 패킷 손실 확인
sudo btmon --write /tmp/a2dp_debug.snoop

# 2. USB autosuspend 비활성화
# Bluetooth 어댑터의 USB 경로 확인
lsusb -t | grep -i bluetooth
echo -1 > /sys/bus/usb/devices/1-3/power/autosuspend_delay_ms

# 3. Wi-Fi 간섭 확인
iw dev wlan0 station dump | grep -E "signal|tx retries"
# Wi-Fi 재전송이 높으면 5GHz로 전환
iw dev wlan0 set channel 36

# 4. A2DP 코덱 확인 (PipeWire)
pw-dump | grep -A5 bluetooth
# SBC -> AAC 또는 LDAC로 변경 시도

시나리오 3: 임베디드 BLE Peripheral 개발

# 리눅스를 BLE Peripheral (GATT Server)로 설정

# 1. 광고 활성화
btmgmt advertising on
btmgmt name "Linux-Sensor"
btmgmt connectable on

# 2. bluetoothd에 GATT 서비스 등록 (D-Bus API 사용)
# Python 예시 (bluez의 example-gatt-server.py 참조)
# dbus.service.Object로 GattService1, GattCharacteristic1 구현

# 3. 광고 데이터에 서비스 UUID 포함
# bluetoothctl: advertise on
# advertise.uuids 0x180D  (Heart Rate Service)

관련 커널 데이터 구조 요약

주요 자료구조 관계

/* include/net/bluetooth/hci_core.h - hci_conn 구조체 주요 필드 */
struct hci_conn {
    struct list_head  list;
    atomic_t          refcnt;

    bdaddr_t          dst;          /* 원격 장치 주소 */
    __u8              dst_type;     /* 주소 타입 (Public/Random) */
    __u16             handle;       /* HCI 연결 핸들 */
    __u16             state;        /* BT_CONNECTED, BT_OPEN 등 */
    __u8              type;         /* ACL_LINK, LE_LINK, SCO_LINK */

    __u8              sec_level;    /* 현재 보안 레벨 */
    __u8              pending_sec_level;

    __u16             le_conn_interval;
    __u16             le_conn_latency;
    __u16             le_supv_timeout;

    struct l2cap_conn *l2cap_data;  /* L2CAP 연결 데이터 */
    struct smp_chan   *smp_chan;    /* SMP 채널 (페어링 중) */

    struct hci_dev   *hdev;        /* 소속 어댑터 */
    void             *l2cap_data;
    void             *sco_data;
    void             *iso_data;
};

참고자료

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