search

bluekitchen / btstack

Dual-mode Bluetooth stack, with small memory footprint.
http://bluekitchen-gmbh.com
Other
1.74k stars 618 forks source link

HCI transport: Add support for Linux HCI socket? #548

Closed AminoACID123 closed 7 months ago

AminoACID123 commented 1 year ago

Is your feature request related to a problem? Please describe. For some reason I need to run Btstack on Linux with a local controller attached and directly accessible via Linux HCI socket. Currently for posix port, Btstack supports uart and usb. I think it would be nice if Btstack supports transport over Linux HCI socket.

Describe the solution you'd like Add support for transport over Linux HCI socket, similar to that in zephyr or nimble

mringwal commented 1 year ago

We've recently added support for FreeBSD's Netgraph Bluetooth HCI driver on the develop branch https://github.com/bluekitchen/btstack/blob/develop/port/freebsd-netgraph/hci_transport_netgraph.c - which required to disable FreeBSD's L2CAP layer, though.

Do you want/need to keep using BlueZ in parallel, or do you only require BlueZ to load/initialized the Bluetooth Controller (which isn't supported by BTstack directly yet)?

AminoACID123 commented 1 year ago

I don't need to use BlueZ in parallel. Btstack application can have exclusive control over the controller. It's fine. I just wonder whether it is possible to make Btstack application send/recv all HCI packets via HCI socket.

mringwal commented 1 year ago

Good, running two Host Stacks with one Controller would be a disaster :) BTstack should be fine once someone implemented hci_transport_t via BueZ' HCI socket. Given the references to Zephyr and NimBLE, it looks like it should just work out of the box (it didn't with FreeBSD which didn't want to send/receive ACL directly).

AminoACID123 commented 7 months ago

I am currently implementing this feature. However, I encountered some problems. I wrote a custom hci_transport_t driver which uses linux bluez socket to send/receive packets. The driver is synchronous, which means can_send_packet_now is NULL. However, in gap_run_set_local_name and gap_run_set_eir_data, hci_reserve_packet_buffer is used to reserve the HCI buffer. I cannot find a way to release the packet buffer under synchronous transport settings. Does that mean I must design the HCI driver as asynchronous?

mringwal commented 7 months ago

Hi @AminoACID123 Please try the current develop branch. gap_run_set_local_name and gap_run_set_eir_data should work with synchronous implementations now as well. In general, please consider if it's possible to implement an asynchronous driver.

AminoACID123 commented 7 months ago

I see. Thank you.