Bluez使用HCI_CHANNEL_USER socket报文件描述符状态错误咨询

尝试在Linux HCI接口上创建HCI_CHANNEL_USER类型socket实现蓝牙适配器操作，核心代码如下：
main.c 逻辑：

int devsocket = open_dev(dev_id);
if(devsocket < 0){
        perror("Unable to open HCI_CHANNEL_USER socket on interface");
        exit(1);
}

printf("HCI_CHANNEL_USER socket open on device %d\n",dev_id);

char name[20];
int ret = hci_read_local_name(devsocket,sizeof(name),name,1000);
if(ret < 0){
        perror("Unable to read local name");
        exit(1);
}
printf("Local name : %s\n",name);

open_dev 函数实现：

int open_dev(int dev_id){

        struct sockaddr_hci a;

        int dd = socket(PF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC, BTPROTO_HCI);

        if (dd < 0){
                perror("Can't create socket");
                return -1;
        }

        printf("[open_dev][+] HCI socket created\n");
       
        if(ioctl(dd,HCIDEVDOWN,dev_id)){
                perror("[open_dev][-] Unable to turn down interface");
                close(dd);
                return -1;
        }

        printf("[open_dev][+] Interface turned off\n");

        if(wait_hcidev(dev_id)){
                perror("[open_dev][-] Interface unavailable");
                close(dd);
                return -1;
        }

        printf("[open_dev][+] Interface available\n");

        memset(&a, 0, sizeof(a));
        a.hci_family = AF_BLUETOOTH;
        a.hci_dev = dev_id;
        a.hci_channel = HCI_CHANNEL_USER;

        if (bind(dd,(struct sockaddr *) &a,sizeof(a)) < 0){
                close(dd);
                perror("[open_dev][-] Unable to bind socket");
                return -1;
        }

        return dd;
}

编译运行后调用hci_read_local_name时返回File descriptor in bad state错误；测试验证如果不设置a.hci_channel=HCI_CHANNEL_USER、不关闭HCI接口，BlueZ提供的API可以正常调用。

• 该通道的核心设计目标是支持用户态进程独占HCI蓝牙控制器，绑定成功后内核自带的BlueZ HCI层会完全释放对目标适配器的控制权，不再介入任何HCI帧的解析、命令处理、事件分发，所有HCI层通信完全由绑定该socket的用户态进程自行处理。
• 典型适用场景包括：用户态自定义蓝牙协议栈开发、蓝牙控制器底层调试、厂商私有HCI命令透传、不需要内核BlueZ协议栈参与的特殊蓝牙功能实现。
• 和普通HCI socket的核心差异：普通HCI socket是和内核BlueZ栈交互，由内核代为完成和控制器的通信、状态维护；HCI_CHANNEL_USER是完全绕过内核BlueZ栈，直接拿到控制器的裸通信通道。

当前代码的核心问题是混用了两套完全不兼容的HCI操作逻辑：

1. hci_read_local_name是BlueZ用户态库提供的高层封装API，这套API的实现逻辑是针对普通HCI socket设计的，依赖内核BlueZ栈维护的适配器状态、命令-事件匹配机制、同步控制逻辑，本质是和内核BlueZ栈做交互，不是直接收发裸HCI帧。
2. 当socket成功绑定HCI_CHANNEL_USER后，内核侧已经将该适配器的控制权完全移交，内核BlueZ层不再维护该适配器的运行状态，也不会响应这套高层API的请求，因此返回文件描述符状态错误是符合设计预期的。
3. 参考实现中绑定HCI_CHANNEL_USER之后不会调用任何BlueZ封装的高层hci_*函数，都是自行组装符合HCI规范的裸命令帧、自行解析控制器返回的裸事件帧。
4. 测试中可正常调用API的场景，本质是退回到了普通HCI socket的工作模式，内核BlueZ栈正常持有控制器控制权，因此BlueZ的高层API可以正常工作。

根据实际开发需求二选一即可：

• 如果是做常规蓝牙应用开发、需要直接使用BlueZ提供的高层API，不要使用HCI_CHANNEL_USER，创建socket后绑定默认HCI通道即可，不需要手动执行HCIDEVDOWN操作关闭接口。
• 如果确实需要使用HCI_CHANNEL_USER独占控制器做底层开发，必须放弃BlueZ提供的hci_*系列封装API，自行按照蓝牙HCI规范构造裸帧收发：比如读取本地名称对应的HCI命令操作码为0x0C14，自行组装HCI命令头通过write()发送到socket，再通过read()读取控制器返回的事件包，自行解析出本地名称字段。
• 注意：绑定HCI_CHANNEL_USER前执行HCIDEVDOWN关闭接口的逻辑是正确的，这是绑定该通道的必要前提，否则bind操作会直接返回失败，绑定成功后内核会自动拉起接口，可直接进行裸帧收发。

内容的提问来源于stack exchange，提问作者sjmz