Hi Thiemo, On Thu, Jun 20, 2019 at 12:53 PM Thiemo van Engelen <tvanengelen@xxxxxxxxxxxxxxxxx> 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
