Re: [PATCH BlueZ 0/3] Add Connectable property to org.bluez.Device

[Kevin Dewald <kevin@simpleble.org>]

Hi Luiz,

On Wed, Sep 30, 2026, Luiz Augusto von Dentz wrote:
> This is already exposed via AdvertisingFlags:
>
> https://github.com/bluez/bluez/blob/master/doc/org.bluez.Device.rst#arraybyte-advertisingflags-readonly
>
> bluetoothctl does already gray the devices that are not considered
> discoverable, see:
>
> commit 815f779aa8e477e399b78f03c0ea0e75f0270c4a

AdvertisingFlags is the Flags AD type, which tells whether a device is
discoverable, not whether it accepts connections. GAP defines the two
modes separately: connectability comes from the advertising PDU type,
which the kernel reports on its own as MGMT_DEV_FOUND_NOT_CONNECTABLE.
bluetoothd already relies on that flag, to skip non-connectable reports
when auto-connecting and to drop temporary non-connectable devices when
discovery stops, but doesn't expose it.

The two often disagree. Beacons commonly send ADV_NONCONN_IND with
Flags 0x06 (e.g. the 02 01 06 prefix of iBeacon), so bluetoothctl shows
them as discoverable although they can't be connected to. A device that
is connectable but not discoverable can send ADV_IND with Flags 0x04
and is grayed out although it accepts connections.

I checked this on an nRF52840 that keeps the same advertising data,
starting with 02 01 06, and only changes the PDU type:

  PDU               AdvertisingFlags  Device Found flags  Connectable
  ADV_IND           0x06              0x00000000          true
  ADV_SCAN_IND      0x06              0x00000004          false
  ADV_NONCONN_IND   0x06              0x00000004          false

The use case is cross-platform code: Android (ScanResult.isConnectable),
Core Bluetooth (CBAdvertisementDataIsConnectable) and Windows
(BluetoothLEAdvertisementReceivedEventArgs.IsConnectable) all report
this, and exposing it would let applications rely on it on Linux too.

I'm happy to mark it experimental, or rework it if you'd prefer a
different shape.

Kevin