Bluetooth L2CAP

Bluetooth L2CAP

We have new L2CAP support in the code repository for L2CAP, currently only for the Broadcom/Widcomm stack. This can be used for your custom application that uses L2CAP, and for some Bluetooth Profiles, for instance HDP (Health Devices) etc.

For the HID Profile most Bluetooth stacks have built-in ‘host’ support for HID and thus connect directly with the HID device and pass the data directly to Windows’ HID support. However some devices have incomplete HID support and thus the protocol stack can’t connect to them, so this L2CAP support can be used to connect directly. It also could be used if one wants to create a HID Device. Depending on the stack, there might be conflicts between the built-in HID services and your implementation however.

API

The API to this is currently two new classes: L2CapClient and L2CapListener which each have a subset of the member on the existing BluetoothClient and BluetoothListener classes — they remain for RFCOMM. However the data stream returned by L2CapClient is subclass of System.IO.Stream rather than a subclass of NetworkStream. This is because whereas RFCOMM presents a stream of data instead L2CAP transfers packets so should use socket type SOCK{""}SEQPACKET rather that SOCK{""}STREAM, and NetworkStream does not support SOCK{"_"}SEQPACKET. See more on data transfer below.

Unfortunately, being Widcomm, updates to the C++ mapping layer are required for this new functionality. These have been added to the 32feetWidcomm.dll source in the repository and the respective DLL need to be recompiled. I can provide access to a built copy based on demand.

Data access

As a SOCK{"_"}SEQPACKET the packet boundaries from the L2CAP protocol should be maintained when reading from the socket/stream, we do that currently, so one Read will not return data from more than one packet, it will return when the end of a packet is reached (or it has filled the caller buffer). However the semantics of SEQPACKET with simple recv are also that if a portion of a packet is read then the rest of the data from that packet should be discarded. We do not do that currently, remaining parts of a packet will be returned in the subsequent reads. We will look at changing that sometime.

Also, the Widcomm platform allows one to do writes bigger that the MTU. We should probably disallow that too.