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

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

[Kevin Dewald]

bluetoothd records whether each advertising report was connectable,
from the Device Found event's Not Connectable flag, and uses it
internally, for example to pick the bearer to connect and to drop
temporary non-connectable devices when discovery stops. Applications
cannot read it over D-Bus, so they have to guess, e.g. from whether the
device has a name, which is wrong for named beacons and for unnamed
peripherals.

This series exposes it as a read-only Connectable property on
org.bluez.Device1, emitted when it first becomes known and whenever it
changes, and prints it in bluetoothctl info.

Tested with an nRF52840 switching between ADV_IND, ADV_SCAN_IND and
ADV_NONCONN_IND advertising: the property follows each change,
including PropertiesChanged in both directions on a device kept by
continuous discovery.

Kevin Dewald (3):
  org.bluez.Device: Add Connectable property
  device: Add Connectable property
  client: Print Connectable in info

 client/main.c            |  1 +
 doc/org.bluez.Device.rst | 11 +++++++++++
 src/device.c             | 36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+)

-- 
2.54.0 (Apple Git-157)

[PATCH BlueZ 1/3] org.bluez.Device: Add Connectable property

[Kevin Dewald]

This adds Connectable property which indicates whether the remote
device accepts connections, as reported by its last advertising report
or inquiry result.

bluetoothd already tracks this per bearer from the Device Found event,
but it is not exposed over D-Bus, so applications cannot tell
connectable advertisers such as peripherals from non-connectable ones
such as beacons without attempting a connection.
---
 doc/org.bluez.Device.rst | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/org.bluez.Device.rst b/doc/org.bluez.Device.rst
index 3e6a30a..abfd74d 100644
--- a/doc/org.bluez.Device.rst
+++ b/doc/org.bluez.Device.rst
@@ -395,6 +395,17 @@ int16 TxPower [readonly, optional]
 
 Advertised transmitted power level (inquiry or advertising).
 
+bool Connectable [readonly, optional]
+`````````````````````````````````````
+
+Indicates whether the remote device accepts connections, based on the most
+recent advertising report or inquiry result. For LE this is false when the
+last advertising report was non-connectable, e.g. ADV_NONCONN_IND or
+ADV_SCAN_IND.
+
+BR/EDR devices are always considered connectable. LE devices only have this
+property once they have been discovered or connected.
+
 dict ManufacturerData [readonly, optional]
 ``````````````````````````````````````````
 
-- 
2.54.0 (Apple Git-157)

[PATCH BlueZ 2/3] device: Add Connectable property

[Kevin Dewald]

This implements Connectable property using device_is_connectable, which
reports whether the last advertising report on the device's bearer was
connectable, and emits PropertiesChanged from device_update_last_seen
when the value changes or first becomes known.
---
 src/device.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/src/device.c b/src/device.c
index c5d8e4c..ae91967 100644
--- a/src/device.c
+++ b/src/device.c
@@ -330,6 +330,14 @@ static struct bearer_state *get_state(struct btd_device *dev,
 		return &dev->le_state;
 }
 
+static bool device_connectable_known(struct btd_device *dev)
+{
+	if (dev->bredr)
+		return true;
+
+	return get_state(dev, dev->bdaddr_type)->last_seen != 0;
+}
+
 bool btd_device_is_initiator(struct btd_device *dev)
 {
 	if (dev->le_state.connected)
@@ -1292,6 +1300,25 @@ static gboolean dev_property_exists_tx_power(const GDBusPropertyTable *property,
 	return TRUE;
 }
 
+static gboolean
+dev_property_get_connectable(const GDBusPropertyTable *property,
+					DBusMessageIter *iter, void *data)
+{
+	struct btd_device *dev = data;
+	dbus_bool_t val = device_is_connectable(dev);
+
+	dbus_message_iter_append_basic(iter, DBUS_TYPE_BOOLEAN, &val);
+
+	return TRUE;
+}
+
+static gboolean
+dev_property_exists_connectable(const GDBusPropertyTable *property,
+								void *data)
+{
+	return device_connectable_known(data);
+}
+
 static gboolean
 dev_property_get_svc_resolved(const GDBusPropertyTable *property,
 					DBusMessageIter *iter, void *data)
@@ -3767,6 +3794,8 @@ static const GDBusPropertyTable device_properties[] = {
 				NULL, dev_property_service_data_exist },
 	{ "TxPower", "n", dev_property_get_tx_power, NULL,
 					dev_property_exists_tx_power },
+	{ "Connectable", "b", dev_property_get_connectable, NULL,
+					dev_property_exists_connectable },
 	{ "ServicesResolved", "b", dev_property_get_svc_resolved, NULL, NULL },
 	{ "AdvertisingFlags", "ay", dev_property_get_flags, NULL,
 					dev_property_flags_exist },
@@ -5352,12 +5381,19 @@ void device_update_last_seen(struct btd_device *device, uint8_t bdaddr_type,
 							bool connectable)
 {
 	struct bearer_state *state;
+	bool known = device_connectable_known(device);
+	bool was_connectable = device_is_connectable(device);
 
 	state = get_state(device, bdaddr_type);
 
 	state->last_seen = time(NULL);
 	state->connectable = connectable;
 
+	if (known != device_connectable_known(device) ||
+			was_connectable != device_is_connectable(device))
+		g_dbus_emit_property_changed(dbus_conn, device->path,
+					DEVICE_INTERFACE, "Connectable");
+
 	if (!device_is_temporary(device))
 		return;
 
-- 
2.54.0 (Apple Git-157)

[PATCH BlueZ 3/3] client: Print Connectable in info

[Kevin Dewald]

This prints the Connectable property with the likes of info command:

bluetoothctl> info <addr>
...
	Connectable: yes
---
 client/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/client/main.c b/client/main.c
index 314aead..c44b81e 100644
--- a/client/main.c
+++ b/client/main.c
@@ -2026,6 +2026,7 @@ static void cmd_info(int argc, char *argv[])
 	print_property(proxy, "ServiceData");
 	print_property(proxy, "RSSI");
 	print_property(proxy, "TxPower");
+	print_property(proxy, "Connectable");
 	print_property(proxy, "AdvertisingFlags");
 	print_property(proxy, "AdvertisingData");
 	print_property(proxy, "Sets");
-- 
2.54.0 (Apple Git-157)

RE: Add Connectable property to org.bluez.Device

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1175652/

---Test result---

Test Summary:
CheckPatch                    PASS      1.49 seconds
GitLint                       FAIL      1.03 seconds
BuildEll                      PASS      19.46 seconds
BluezMake                     PASS      384.18 seconds
MakeCheck                     PASS      15.41 seconds
MakeDistcheck                 PASS      144.68 seconds
CheckValgrind                 PASS      233.64 seconds
CheckSmatch                   PASS      292.40 seconds
bluezmakeextell               PASS      93.89 seconds
TestFunctional                PASS      1111.71 seconds
IncrementalBuild              PASS      392.97 seconds
ScanBuild                     PASS      1134.60 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,3/3] client: Print Connectable in info

7: B3 Line contains hard tab characters (\t): "	Connectable: yes"


https://github.com/bluez/bluez/pull/2602

---
Regards,
Linux Bluetooth

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

[Luiz Augusto von Dentz]

Hi Kevin,

On Mon, Sep 28, 2026 at 6:39 PM Kevin Dewald <kevin@simpleble.org> wrote:
>
> bluetoothd records whether each advertising report was connectable,
> from the Device Found event's Not Connectable flag, and uses it
> internally, for example to pick the bearer to connect and to drop
> temporary non-connectable devices when discovery stops. Applications
> cannot read it over D-Bus, so they have to guess, e.g. from whether the
> device has a name, which is wrong for named beacons and for unnamed
> peripherals.
>
> This series exposes it as a read-only Connectable property on
> org.bluez.Device1, emitted when it first becomes known and whenever it
> changes, and prints it in bluetoothctl info.
>
> Tested with an nRF52840 switching between ADV_IND, ADV_SCAN_IND and
> ADV_NONCONN_IND advertising: the property follows each change,
> including PropertiesChanged in both directions on a device kept by
> continuous discovery.
>
> Kevin Dewald (3):
>   org.bluez.Device: Add Connectable property
>   device: Add Connectable property
>   client: Print Connectable in info
>
>  client/main.c            |  1 +
>  doc/org.bluez.Device.rst | 11 +++++++++++
>  src/device.c             | 36 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 48 insertions(+)
>
> --
> 2.54.0 (Apple Git-157)

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
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Mar 6 16:48:43 2023 -0800

    client: Use AdvertisingFlags when available

    This prints devices not discoverable in grey so the user are able to
    distict when for example set members are actually visible.


-- 
Luiz Augusto von Dentz

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

[Kevin Dewald]

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

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

[Luiz Augusto von Dentz]

Hi Kevin,

On Wed, Sep 30, 2026 at 4:30 PM Kevin Dewald <kevin@simpleble.org> wrote:
>
> 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.

/* BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part C
* page 2042:
* A device in the broadcast mode -> shall <- not set the
* ‘LE General Discoverable Mode’ flag or the
* ‘LE Limited Discoverable Mode’ flag in the Flags AD Type
* as defined in [Core Specification Supplement], Part A,
* Section 1.3.
*/
Still there on 6.3:
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core_v6.3/out/en/host/generic-access-profile.html#UUID-e4fb40c0-af64-b2b3-d141-52cc77603ffd

So the iBeacon is not following the spec when it comes to setting
discoverable flags then.

> 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

ADV_NONCONN_IND (Broadcast mode) so setting any discoverable bits
shall not be allowed, Im surprised stacks even allow such combination
since this may confuse UIs that may show the device even though it is
not connectable.

> 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.

That makes sense now, I jumped to the conclusion you were talking
about the discoverable flag rather than whether it is connectable.

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

I'm not against it since some stacks allow the combination
ADV_NONCONN_IND with ‘LE General Discoverable Mode’ flag or the ‘LE
Limited Discoverable Mode’ flag, when it is clearly not allowed as per
spec, that said in case it is a dual-mode device then we need the
Connectable also in a per bearer interface to reflect what bearer
would be connectable, or at least on LE bearer since classic is always
connectable, an I would print in red in bluetoothctl to warn user it
is a discoverable broadcaster.

-- 
Luiz Augusto von Dentz