Re: Bluetooth: possible bug and question

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Mon, 18 Aug 2025, Mouse wrote:

> (I trust tech-net is suitable for bluetooth matters.  If not, I'll be
> happy to move this elsewhere; just tell me where.)
> 
> The possible bug:
> 
> In general, HCI_CMD_foo and HCI_OCF_foo have the same low octet.  But
> when foo is SNIFF_SUBRATING, they don't.  This makes
> HCI_CMD_SNIFF_SUBRATING collide with HCI_CMD_FLOW_SPECIFICATION.
> 
> This has been so since, at least, 5.2, and I checked cvsweb from a work
> machine today (I have the 10.1 source trickling over, but that will
> take time; while I think I understand why it's done, it _is_ broken for
> access from my own machines), which makes me think it's so in -current
> as well.
> 
> Is this a bug, or am I missing something?

Yes, looks like a copy-paste bug.

The CMD is constructed by OR of the OGF and OCF, so the command should be 
0x811. I have fixed it in -current just now. Could issue pullups to 
netbsd-9 and netbsd-10, but it is otherwise unused so not sure if really 
an issue.

In fact I have resisted adding definitions from later specifications, 
since they are not often relevant (also, laziness)

> The question:
> 
> I'm trying to implement some bluetooth code (on 5.2).  What I'm trying
> to implement at the moment is the ability to play audio through a
> bluetooth speaker, but that's just a first task; I'd like to implement
> other things.

there is a bta2dpd daemon written by Nat Sloss, I don't recall exactly 
when that was imported (written 2015)

> I'm running into trouble, and I suspect much of the trouble arises
> because I'm missing some important concents and how they relate to one
> another.  (As one simple example, it is not clear to me how HCI, L2CAP,
> RFCOMM, and SCO relate to one another, and, except for what I can infer
> from manpages like btsco(4), it's unclear when I'd want which one.)  Is
> there a reference anyone would recommend?

HCI is host-controller interface. It is how the OS speaks to the hardware 
in order to control it and is not a way to send data to remote hardware

SCO is an isochronous data protocol, for time sensitive data with no 
reliability (I think out of time data is just dropped)

L2CAP is a sequential packet transfer protocol with supposedly some 
reliability.

all of the other protocols, including RFCOMM (a serial data protocol) are 
layered on top of L2CAP as you can multiplex many L2CAP channels over a 
baseband connection.

there are two ways to send audio.

The first is via isochronous streaming, this goes over the SCO channels 
and can be accessed either via sockets (BTPROTO_SCO) or btsco(4) device 
and using the bthset(1) program. This is used for telephony, if you wish 
to use Bluetooth a headset or earpiece, it is mono and bi-directional. You 
generally need to configure the adaptor specificially for this, it is not 
automatically available.

The second way is using the A2DP profile, which uses various protocols 
layered over L2CAP. It can handle audio compression, also signalling for 
remote controls. A2DP is not necessarily time sensitive, the audio may be 
buffered to account for any loss of connection. Also I don't think it is 
natively bi-directional, a connection is either a sink or a source, which 
is not to say that a device can't be both at the same time.

iain