2023-03-03 14:52:32

by Iulia Tanasescu

[permalink] [raw]
Subject: ISO socket bugs/lack of support

Hello,

Earlier this week I submitted a BlueZ patch ([1]) containing an initial implementation of the Broadcast Audio Scan Service.

In order to perform some of the BASS procedures, the BASS Server is required to send specific HCI commands and to handle HCI events accordingly - for example, the "Set Broadcast_Code" operation of the Broadcast Audio Scan Control Point characteristic requires the BASS Server to issue the LE BIG Create Sync command with the Broadcast_Code parameter set to the characteristic value written by the BASS Client.

My approach was to open an HCI socket and to send the command directly from the BASS handler function. After my proposed implementation was reviewed, I was told I should use an ISO socket instead and let the Bluetooth kernel perform the BIG synchronization procedure. I investigated this solution and the problem that I encountered was that the kernel sends HCI commands with fixed parameters - calling the "listen" API on an ISO socket will always attempt to send the LE BIG Create Sync command with the Broadcast_Code parameter set to 0. I couldn't find a way to provide my desired parameters to the HCI command.

I also discovered 2 kernel issues when calling "listen" on an ISO socket:

The first issue is that the "hci_pa_create_sync" function attempts to send the LE Periodic Advertising Create Sync command with the Sync_Timeout parameter set to 0 - according to the Bluetooth Core specification version 5.3, this parameter should be in the 0x000A - 0x4000 range. This is why the Controller will reject this command, as shown in the following btmon capture:


< HCI Command: LE Periodic Advertising Create Sync (0x08|0x0044) plen 14
Options: 0x0000
Use advertising SID, Advertiser Address Type and address
Reporting initially enabled
SID: 0x01
Adv address type: Public (0x00)
Adv address: C0:07:E8:8B:69:F2 (OUI C0-07-E8)
Skip: 0x0000
Sync timeout: 0 msec (0x0000)
Sync CTE type: 0x0000

> HCI Event: Command Status (0x0f) plen 4
LE Periodic Advertising Create Sync (0x08|0x0044) ncmd 1
Status: Invalid HCI Command Parameters (0x12)

Updating the "hci_pa_create_sync" function and setting the "sync_timeout" field of the command parameters to a value in the required range solves the problem.

The same issue appears when the kernel attempts to send the LE BIG Create Sync command with the BIG_Sync_Timeout parameter set to 0:


< HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b) plen 25
BIG Handle: 0x00
BIG Sync Handle: 0x0000
Encryption: Encrypted (0x00)
Broadcast Code: 00000000000000000000000000000000
Maximum Number Subevents: 0x00
Timeout: 0 ms (0x0000)
Number of BIS: 1
BIS ID: 0x01

> HCI Event: Command Status (0x0f) plen 4
LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
Status: Parameter Out Of Manadatory Range (0x30)

Updating the "hci_le_big_create_sync" function and setting the "timeout" field of the command parameters to a valid value solves the issue.

Hopefully someone can confirm the kernel issues I described and the fixes can be committed. I would also like to ask for some guidance regarding the ISO socket usage when it comes to personalizing HCI command parameters - is there a way to set the parameters from BlueZ? Or should this support be implemented in the Bluetooth kernel?

Thank you in advance

Iulia

[1] [BlueZ,0/2] Add initial BASS support - Patchwork (kernel.org)



2023-03-03 17:49:00

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: ISO socket bugs/lack of support

Hi Iulia,

On Fri, Mar 3, 2023 at 7:02 AM Iulia Tanasescu <[email protected]> wrote:
>
> Hello,
>
> Earlier this week I submitted a BlueZ patch ([1]) containing an initial implementation of the Broadcast Audio Scan Service.
>
> In order to perform some of the BASS procedures, the BASS Server is required to send specific HCI commands and to handle HCI events accordingly - for example, the "Set Broadcast_Code" operation of the Broadcast Audio Scan Control Point characteristic requires the BASS Server to issue the LE BIG Create Sync command with the Broadcast_Code parameter set to the characteristic value written by the BASS Client.
>
> My approach was to open an HCI socket and to send the command directly from the BASS handler function. After my proposed implementation was reviewed, I was told I should use an ISO socket instead and let the Bluetooth kernel perform the BIG synchronization procedure. I investigated this solution and the problem that I encountered was that the kernel sends HCI commands with fixed parameters - calling the "listen" API on an ISO socket will always attempt to send the LE BIG Create Sync command with the Broadcast_Code parameter set to 0. I couldn't find a way to provide my desired parameters to the HCI command.
>
> I also discovered 2 kernel issues when calling "listen" on an ISO socket:
>
> The first issue is that the "hci_pa_create_sync" function attempts to send the LE Periodic Advertising Create Sync command with the Sync_Timeout parameter set to 0 - according to the Bluetooth Core specification version 5.3, this parameter should be in the 0x000A - 0x4000 range. This is why the Controller will reject this command, as shown in the following btmon capture:
>
>
> < HCI Command: LE Periodic Advertising Create Sync (0x08|0x0044) plen 14
> Options: 0x0000
> Use advertising SID, Advertiser Address Type and address
> Reporting initially enabled
> SID: 0x01
> Adv address type: Public (0x00)
> Adv address: C0:07:E8:8B:69:F2 (OUI C0-07-E8)
> Skip: 0x0000
> Sync timeout: 0 msec (0x0000)
> Sync CTE type: 0x0000
>
> > HCI Event: Command Status (0x0f) plen 4
> LE Periodic Advertising Create Sync (0x08|0x0044) ncmd 1
> Status: Invalid HCI Command Parameters (0x12)
>
> Updating the "hci_pa_create_sync" function and setting the "sync_timeout" field of the command parameters to a value in the required range solves the problem.

Broadcast support is in its very early stages of development, and yes
the sync_timeout probably need fixing as it using invalid range right
now, we should probably a way to configure it via use of BT_ISO_QOS,
currently both unicast and broadcast are using the same structure but
perhaps it would be a good idea to differentiate them with more
dedicated options.

> The same issue appears when the kernel attempts to send the LE BIG Create Sync command with the BIG_Sync_Timeout parameter set to 0:
>
>
> < HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b) plen 25
> BIG Handle: 0x00
> BIG Sync Handle: 0x0000
> Encryption: Encrypted (0x00)
> Broadcast Code: 00000000000000000000000000000000
> Maximum Number Subevents: 0x00
> Timeout: 0 ms (0x0000)
> Number of BIS: 1
> BIS ID: 0x01
>
> > HCI Event: Command Status (0x0f) plen 4
> LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
> Status: Parameter Out Of Manadatory Range (0x30)
>
> Updating the "hci_le_big_create_sync" function and setting the "timeout" field of the command parameters to a valid value solves the issue.

Patches are welcome to fix this as well.

> Hopefully someone can confirm the kernel issues I described and the fixes can be committed. I would also like to ask for some guidance regarding the ISO socket usage when it comes to personalizing HCI command parameters - is there a way to set the parameters from BlueZ? Or should this support be implemented in the Bluetooth kernel?

The setup of Qos is done via BT_ISO_QOS:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/include/net/bluetooth/bluetooth.h#n174

As you can see currently the structure is targeting unicast
parameters, we should probably split this and have a dedicated one for
broadcast.

> Thank you in advance
>
> Iulia
>
> [1] [BlueZ,0/2] Add initial BASS support - Patchwork (kernel.org)
>


--
Luiz Augusto von Dentz

2023-03-15 19:42:53

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: ISO socket bugs/lack of support

Hi Iulia,

On Fri, Mar 3, 2023 at 9:48 AM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Iulia,
>
> On Fri, Mar 3, 2023 at 7:02 AM Iulia Tanasescu <[email protected]> wrote:
> >
> > Hello,
> >
> > Earlier this week I submitted a BlueZ patch ([1]) containing an initial implementation of the Broadcast Audio Scan Service.
> >
> > In order to perform some of the BASS procedures, the BASS Server is required to send specific HCI commands and to handle HCI events accordingly - for example, the "Set Broadcast_Code" operation of the Broadcast Audio Scan Control Point characteristic requires the BASS Server to issue the LE BIG Create Sync command with the Broadcast_Code parameter set to the characteristic value written by the BASS Client.
> >
> > My approach was to open an HCI socket and to send the command directly from the BASS handler function. After my proposed implementation was reviewed, I was told I should use an ISO socket instead and let the Bluetooth kernel perform the BIG synchronization procedure. I investigated this solution and the problem that I encountered was that the kernel sends HCI commands with fixed parameters - calling the "listen" API on an ISO socket will always attempt to send the LE BIG Create Sync command with the Broadcast_Code parameter set to 0. I couldn't find a way to provide my desired parameters to the HCI command.
> >
> > I also discovered 2 kernel issues when calling "listen" on an ISO socket:
> >
> > The first issue is that the "hci_pa_create_sync" function attempts to send the LE Periodic Advertising Create Sync command with the Sync_Timeout parameter set to 0 - according to the Bluetooth Core specification version 5.3, this parameter should be in the 0x000A - 0x4000 range. This is why the Controller will reject this command, as shown in the following btmon capture:
> >
> >
> > < HCI Command: LE Periodic Advertising Create Sync (0x08|0x0044) plen 14
> > Options: 0x0000
> > Use advertising SID, Advertiser Address Type and address
> > Reporting initially enabled
> > SID: 0x01
> > Adv address type: Public (0x00)
> > Adv address: C0:07:E8:8B:69:F2 (OUI C0-07-E8)
> > Skip: 0x0000
> > Sync timeout: 0 msec (0x0000)
> > Sync CTE type: 0x0000
> >
> > > HCI Event: Command Status (0x0f) plen 4
> > LE Periodic Advertising Create Sync (0x08|0x0044) ncmd 1
> > Status: Invalid HCI Command Parameters (0x12)
> >
> > Updating the "hci_pa_create_sync" function and setting the "sync_timeout" field of the command parameters to a value in the required range solves the problem.
>
> Broadcast support is in its very early stages of development, and yes
> the sync_timeout probably need fixing as it using invalid range right
> now, we should probably a way to configure it via use of BT_ISO_QOS,
> currently both unicast and broadcast are using the same structure but
> perhaps it would be a good idea to differentiate them with more
> dedicated options.
>
> > The same issue appears when the kernel attempts to send the LE BIG Create Sync command with the BIG_Sync_Timeout parameter set to 0:
> >
> >
> > < HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b) plen 25
> > BIG Handle: 0x00
> > BIG Sync Handle: 0x0000
> > Encryption: Encrypted (0x00)
> > Broadcast Code: 00000000000000000000000000000000
> > Maximum Number Subevents: 0x00
> > Timeout: 0 ms (0x0000)
> > Number of BIS: 1
> > BIS ID: 0x01
> >
> > > HCI Event: Command Status (0x0f) plen 4
> > LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
> > Status: Parameter Out Of Manadatory Range (0x30)
> >
> > Updating the "hci_le_big_create_sync" function and setting the "timeout" field of the command parameters to a valid value solves the issue.
>
> Patches are welcome to fix this as well.
>
> > Hopefully someone can confirm the kernel issues I described and the fixes can be committed. I would also like to ask for some guidance regarding the ISO socket usage when it comes to personalizing HCI command parameters - is there a way to set the parameters from BlueZ? Or should this support be implemented in the Bluetooth kernel?
>
> The setup of Qos is done via BT_ISO_QOS:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/include/net/bluetooth/bluetooth.h#n174
>
> As you can see currently the structure is targeting unicast
> parameters, we should probably split this and have a dedicated one for
> broadcast.
>

Are you still planning to do the BASS support or you need more
feedback? I hope I didn't discourage you since we do appreciate
contributions.



--
Luiz Augusto von Dentz