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
