Double flags field in LE advertising data

Double flags field in LE advertising data

[Thiemo van Engelen]

Hi,

We have an embedded device with Bluez 5.50, kernel 4.19 and a bluetooth
controller where we disable br/edr.
When we start an LE advertisement and set the Discoverable property (of
the advertisment, not the adapter) to True, the advertised packet
contains 2 flag fields, containing different values. See the following
btmon log of the device:

< HCI Command: LE Set Advertising Data (0x08|0x0008) plen
32                                                                     
                                                                       
             #211 [hci0] 1656.561908
        Length: 24
        Flags: 0x04
          BR/EDR Not Supported
        128-bit Service UUIDs (complete): 1 entry
          Vendor specific (cd54c001-880b-425b-b167-81ed6a15e913)
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported

This is not allowed according to the "Supplement to Bluetooth Core
Specification" and the fact that both fields are different seems to
confuse other devices.

The flags are added twice because bluetoothd appends a flags field in
the parse_discoverable / set_flags functions (since commit eca59ac27),
but the kernel also adds a flags field in the function
create_instance_adv_data when BREDR is disabled. 

Perhaps the way to solve this is by not adding the flags field to the
advertisement data, but changing client->flags in accordance with the
Discoverable property and passing that to the kernel using the
mgmt_cp_add_advertising struct (which is already done). The kernel is
then solely responsible for flags. I however have no idea if the flags
passed this way are also used used for BREDR advertising or not.

Kind Regards,

Thiemo van Engelen

Re: Double flags field in LE advertising data

[Luiz Augusto von Dentz]

Hi Thiemo,

On Thu, Jun 20, 2019 at 12:53 PM Thiemo van Engelen
<tvanengelen@victronenergy.com> wrote:
>
> Hi,
>
> We have an embedded device with Bluez 5.50, kernel 4.19 and a bluetooth
> controller where we disable br/edr.
> When we start an LE advertisement and set the Discoverable property (of
> the advertisment, not the adapter) to True, the advertised packet
> contains 2 flag fields, containing different values. See the following
> btmon log of the device:
>
> < HCI Command: LE Set Advertising Data (0x08|0x0008) plen
> 32
>
>              #211 [hci0] 1656.561908
>         Length: 24
>         Flags: 0x04
>           BR/EDR Not Supported
>         128-bit Service UUIDs (complete): 1 entry
>           Vendor specific (cd54c001-880b-425b-b167-81ed6a15e913)
>         Flags: 0x06
>           LE General Discoverable Mode
>           BR/EDR Not Supported
>
> This is not allowed according to the "Supplement to Bluetooth Core
> Specification" and the fact that both fields are different seems to
> confuse other devices.
>
> The flags are added twice because bluetoothd appends a flags field in
> the parse_discoverable / set_flags functions (since commit eca59ac27),
> but the kernel also adds a flags field in the function
> create_instance_adv_data when BREDR is disabled.

Interesting I guess that is a problem only when BR/EDR is disabled
since I tested this and the kernel would be adding any flags, anyway
the kernel should check if the flags have been set and don't attempt
to set it again.

> Perhaps the way to solve this is by not adding the flags field to the
> advertisement data, but changing client->flags in accordance with the
> Discoverable property and passing that to the kernel using the
> mgmt_cp_add_advertising struct (which is already done). The kernel is
> then solely responsible for flags. I however have no idea if the flags
> passed this way are also used used for BREDR advertising or not.
>
> Kind Regards,
>
> Thiemo van Engelen
>


-- 
Luiz Augusto von Dentz