On Mon, Aug 24, 2020 at 3:56 PM Matias N. <mat...@imap.cc> wrote: > That's quite a strange stack arrangement. If you go to the BLE spec, the > L2CAP sits above the HCI layer. > I would guess that the arrow between L2CAP and Bluez actually speaks the > HCI protocol and the "HCI sockets" allow you to directly call into the HCI > layer. I was under the impression that you wouldn't need to "skip layers" > to access all functionality of the LL, but I understand then why the > proposal of exposing the HCI layer via sockets. >
The HCI socket interface does not directly map to the HCI interface of the controller. There are three different channels defined:#define HCI_CHANNEL_RAW 0 #define HCI_CHANNEL_RAW 0 #define HCI_CHANNEL_USER 1 #define HCI_CHANNEL_MONITOR 2 #define HCI_CHANNEL_CONTROL 3 HCI_CHANNEL_USER removes the rest of the bluetooth stack from the controller so that you dont have things like the L2CAP interface messing with the device. This can be super useful, it's actually what I am using to allow the NuttX sim to control my bluetooth hardware. This is in contrast to HCI_CHANNEL_RAW which does not unhook the rest of the stack so you can have multiple things now trying to control the hardware and you have to be careful. RAW is not recommended anymore. HCI_CHANNEL_MONITOR is somewhat self explanatory, but it lets you see all the transactions that are taking place over the HCI interface (including in bluez core). This is usually what something like wireshark will use. HCI_CHANNEL_CONTROL is the "new" control interface that speaks via the management API. This is what bluetoothd would be using to do things like advertise a new service. I wish this was better documented, but it is scattered around and bits of knowledge that I picked up writing a bluetooth mesh stack before it was included in Linux. Hopefully that is helpful, Brennan
