[PATCH BlueZ] shared/gatt-client: discover the CCC descriptor instead of assuming it

[PATCH BlueZ] shared/gatt-client: discover the CCC descriptor instead of assuming it

[Proxy alt]

discover_descs() skips descriptor discovery when a notify/indicate
characteristic has exactly one descriptor handle, inserting a synthesized
0x2902 into the database without ever querying the peer. The assumption
follows Core Spec Vol 3, Part G, 3.3.1.1 - notify or indicate implies a CCC
- but it is applied to hardware that does not honour that clause.

On Telink TLSR825x based devices (GE Cync bulbs and switches) the only
descriptor of the notify characteristic is a 0x2901 Characteristic User
Description reading "Status". No CCC exists anywhere on the service. btmon
shows FIND_INFORMATION_REQ issued for the descriptor slot following every
other characteristic and never for this one: the only slot skipped is the
one following the only characteristic declaring notify.

StartNotify then writes 0100 into that text descriptor. The device leaves
the Write Request unanswered - its own violation - the ATT transaction
timeout expires 30 seconds later, and a connection that was carrying live
notification traffic throughout is torn down. The client is handed
UNLIKELY_ERROR, which never appeared on the wire. The synthesized
descriptor is also written to the GATT cache, and regenerated there on
every fresh discovery, so removing the device does not clear it.

Removing the shortcut costs one round trip per notify characteristic per
discovery and lets the peer answer for itself. Where a CCC genuinely
exists, nothing changes. Where it does not, gatt_db_attribute_get_ccc()
returns NULL, chrc->ccc_handle stays zero, and register_notify() already
handles that case correctly - it completes the request and registers the
handler locally without writing anything. Notifications are dispatched on
a value handle match, so they continue to be delivered, and the link
survives.

Reported and reproduced on three units across two OUI families, one of
which had never been connected before.

unit/test-gatt is unaffected: 192/193 passing, 0 failed, identical before
and after (the one not-run case is pre-existing). No test database has a
notify or indicate characteristic with a single descriptor handle, so
nothing in the suite exercises the shortcut being removed - which is also
how it went nine years without anyone noticing it guesses wrong.

Fixes: https://github.com/bluez/bluez/issues/2383
Signed-off-by: Proxy alt <proxy-alt@proxy-alt.dev>
---
 src/shared/gatt-client.c | 19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/src/shared/gatt-client.c b/src/shared/gatt-client.c
--- a/src/shared/gatt-client.c
+++ b/src/shared/gatt-client.c
@@ -772,31 +772,12 @@
 			free(chrc_data);
 			continue;
 		}
 
 		desc_start = chrc_data->value_handle + 1;
 
-		if (desc_start == chrc_data->end_handle &&
-			(chrc_data->properties & BT_GATT_CHRC_PROP_NOTIFY ||
-			 chrc_data->properties & BT_GATT_CHRC_PROP_INDICATE)) {
-			bt_uuid_t ccc_uuid;
-
-			/* If there is only one descriptor that must be the CCC
-			 * in case either notify or indicate are supported.
-			 */
-			bt_uuid16_create(&ccc_uuid,
-					GATT_CLIENT_CHARAC_CFG_UUID);
-			attr = gatt_db_insert_descriptor(client->db, desc_start,
-							&ccc_uuid, 0, NULL,
-							NULL, NULL);
-			if (attr) {
-				free(chrc_data);
-				continue;
-			}
-		}
-
 		/* Check if the start range is within characteristic range */
 		if (desc_start > chrc_data->end_handle) {
 			free(chrc_data);
 			continue;
 		}
 
-- 
2.51.0

Re: [PATCH BlueZ] shared/gatt-client: discover the CCC descriptor instead of assuming it

[Proxy alt]

v1 breaks unit/test-bap, unit/test-mcp and unit/test-rap. MakeDistcheck
caught it; I had run unit/test-gatt rather than make check before sending,
which is my mistake and why the commit message says less than it should.

Those three profiles have notify characteristics whose descriptor range is a
single handle, so on current master the synthesis fires and no
FIND_INFORMATION goes out for them. With the shortcut removed, discovery
asks, and a 5-byte FIND_INFORMATION_REQ appears where the expected sequence
had the next operation:

  ERROR:src/shared/tester.c:990:test_io_recv: assertion failed
        (len == iov->iov_len): (5 == 7)

Everything after that shifts by one exchange and the tester aborts on the
first mismatch. unit/test-gatt itself is unaffected - 192/193, identical
before and after - but that is one suite, and stating it in the commit
message implied a coverage I had not actually established.

I still believe the change is correct. With the shortcut gone,
gatt_db_attribute_get_ccc() returns NULL, chrc->ccc_handle stays zero, and
register_notify() already completes the request and registers the handler
locally without writing anything.

That is now confirmed on the affected hardware, using tools/btgatt-client
built from 690c16d, same device and adapter minutes apart:

  before   descr - handle: 0x0013, uuid: 00002902-...
           < 12 13 00 01 00
           att: Operation timed out: 0x12
           Failed to register notify handler - error code: 0x0e
           Device disconnected

  after    discover_descs_cb() handle: 0x0013, uuid: 00002901-...
           Registering notify handler with id: 1
           zero writes to 0x0013, no error, link held for the full window

So the device's real attribute at that handle is a 0x2901 User Description,
and once BlueZ asks rather than assumes, notify registration succeeds and
the connection survives.

v2 to follow with the expected PDU sequences in those three tests updated to
include the FIND_INFORMATION exchanges that discovery now performs.

RE: [BlueZ] shared/gatt-client: discover the CCC descriptor instead of assuming it

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1622 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/project/bluetooth/list/?series=1142517

---Test result---

Test Summary:
CheckPatch                    PASS      0.32 seconds
GitLint                       PASS      0.22 seconds
BuildEll                      PASS      18.42 seconds
BluezMake                     PASS      571.13 seconds
MakeCheck                     PASS      0.98 seconds
MakeDistcheck                 FAIL      118.10 seconds
CheckValgrind                 PASS      144.24 seconds
CheckSmatch                   PASS      249.75 seconds
bluezmakeextell               PASS      89.99 seconds
IncrementalBuild              PASS      574.78 seconds
ScanBuild                     PASS      809.47 seconds

Details
##############################
Test: MakeDistcheck - FAIL
Desc: Run Bluez Make Distcheck
Output:

../../test-driver: line 107: 52684 Aborted                 (core dumped) "$@" > $log_file 2>&1
../../test-driver: line 107: 52701 Aborted                 (core dumped) "$@" > $log_file 2>&1
../../test-driver: line 107: 52964 Aborted                 (core dumped) "$@" > $log_file 2>&1
make[4]: *** [Makefile:10247: test-suite.log] Error 1
make[3]: *** [Makefile:10355: check-TESTS] Error 2
make[2]: *** [Makefile:10826: check-am] Error 2
make[1]: *** [Makefile:10828: check] Error 2
make: *** [Makefile:10749: distcheck] Error 1


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

---
Regards,
Linux Bluetooth

[PATCH v2] shared/gatt-client: discover the CCC descriptor instead of assuming it

[Proxy alt]

discover_descs() skips descriptor discovery when a notify/indicate
characteristic has exactly one descriptor handle, inserting a synthesized
0x2902 into the database without ever querying the peer. The assumption
follows Core Spec Vol 3, Part G, 3.3.1.1 - notify or indicate implies a CCC
- but it is applied to hardware that does not honour that clause.

On Telink TLSR825x based devices (GE Cync bulbs and switches) the only
descriptor of the notify characteristic is a 0x2901 Characteristic User
Description reading "Status". No CCC exists anywhere on the service. btmon
shows FIND_INFORMATION_REQ issued for the descriptor slot following every
other characteristic and never for this one: the only slot skipped is the
one following the only characteristic declaring notify.

StartNotify then writes 0100 into that text descriptor. The device leaves
the Write Request unanswered - its own violation - the ATT transaction
timeout expires 30 seconds later, and a connection that was carrying live
notification traffic throughout is torn down. The client is handed
UNLIKELY_ERROR, which never appeared on the wire. The synthesized
descriptor is also written to the GATT cache, and regenerated there on
every fresh discovery, so removing the device does not clear it.

Removing the shortcut costs one round trip per notify characteristic per
discovery and lets the peer answer for itself. Where a CCC genuinely
exists, nothing changes. Where it does not, gatt_db_attribute_get_ccc()
returns NULL, chrc->ccc_handle stays zero, and register_notify() already
handles that case correctly - it completes the request and registers the
handler locally without writing anything. Notifications are dispatched on
a value handle match, so they continue to be delivered, and the link
survives.

Confirmed on the affected hardware with tools/btgatt-client, same device
and adapter minutes apart:

  before   descr - handle: 0x0013, uuid: 00002902-...
           < 12 13 00 01 00
           att: Operation timed out: 0x12
           Failed to register notify handler - error code: 0x0e
           Device disconnected

  after    discover_descs_cb() handle: 0x0013, uuid: 00002901-...
           Registering notify handler with id: 1
           no write to 0x0013, no error, link held

unit/test-bap, unit/test-mcp and unit/test-rap are updated. Their expected
PDU sequences omitted descriptor discovery for exactly those
characteristics whose CCC was being synthesized, so the test data encoded
the shortcut rather than the protocol. test-mcp says so directly - its
MCS_FIND_CHRC comment lists Find Information only "for each missing CCC
HND", the notify characteristics being absent because BlueZ never asked
about them. Now that it asks, those exchanges appear and are expected.

make check: 32/32 suites, 0 failures.

Fixes: https://github.com/bluez/bluez/issues/2383
Signed-off-by: Proxy alt <proxy-alt@proxy-alt.dev>
---
 src/shared/gatt-client.c | 19 -----------------
 unit/test-bap.c          | 44 ++++++++++++++++++++++++++++++++++++++++
 unit/test-mcp.c          | 30 ++++++++++++++++++++++++++-
 unit/test-rap.c          | 25 +++++++++--------------
 4 files changed, 83 insertions(+), 35 deletions(-)

diff --git a/src/shared/gatt-client.c b/src/shared/gatt-client.c
index a6abe8a..0dc656d 100644
--- a/src/shared/gatt-client.c
+++ b/src/shared/gatt-client.c
@@ -775,25 +775,6 @@ static bool discover_descs(struct discovery_op *op, bool *discovering)
 
 		desc_start = chrc_data->value_handle + 1;
 
-		if (desc_start == chrc_data->end_handle &&
-			(chrc_data->properties & BT_GATT_CHRC_PROP_NOTIFY ||
-			 chrc_data->properties & BT_GATT_CHRC_PROP_INDICATE)) {
-			bt_uuid_t ccc_uuid;
-
-			/* If there is only one descriptor that must be the CCC
-			 * in case either notify or indicate are supported.
-			 */
-			bt_uuid16_create(&ccc_uuid,
-					GATT_CLIENT_CHARAC_CFG_UUID);
-			attr = gatt_db_insert_descriptor(client->db, desc_start,
-							&ccc_uuid, 0, NULL,
-							NULL, NULL);
-			if (attr) {
-				free(chrc_data);
-				continue;
-			}
-		}
-
 		/* Check if the start range is within characteristic range */
 		if (desc_start > chrc_data->end_handle) {
 			free(chrc_data);
diff --git a/unit/test-bap.c b/unit/test-bap.c
index 4e89ba6..d4ad20e 100644
--- a/unit/test-bap.c
+++ b/unit/test-bap.c
@@ -355,6 +355,42 @@ static const struct iovec setup_data[] = {
 	 *   Handle range: 0x0001-0xffff
 	 *   Attribute type: Database Hash (0x2b2a)
 	 */
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x04, 0x00, 0x04, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x04, 0x00, 0x02, 0x29),
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x07, 0x00, 0x07, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x07, 0x00, 0x02, 0x29),
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x0a, 0x00, 0x0a, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x0a, 0x00, 0x02, 0x29),
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x0d, 0x00, 0x0d, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x0d, 0x00, 0x02, 0x29),
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x10, 0x00, 0x10, 0x00),
+	IOV_DATA(0x05, 0x01, 0x10, 0x00, 0x02, 0x29),
+	IOV_DATA(0x04, 0x13, 0x00, 0x13, 0x00),
+	IOV_DATA(0x05, 0x01, 0x13, 0x00, 0x02, 0x29),
+	IOV_DATA(0x04, 0x17, 0x00, 0x17, 0x00),
+	IOV_DATA(0x05, 0x01, 0x17, 0x00, 0x02, 0x29),
+	IOV_DATA(0x04, 0x1a, 0x00, 0x1a, 0x00),
+	IOV_DATA(0x05, 0x01, 0x1a, 0x00, 0x02, 0x29),
+	IOV_DATA(0x04, 0x1d, 0x00, 0x1d, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x1d, 0x00, 0x02, 0x29),
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x20, 0x00, 0x20, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x20, 0x00, 0x02, 0x29),
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x23, 0x00, 0x23, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x23, 0x00, 0x02, 0x29),
 	IOV_DATA(0x08, 0x01, 0x00, 0xff, 0xff, 0x2a, 0x2b),
 	/* ATT: Error Response (0x01) len 4
 	 *   Read By Type Request (0x08)
@@ -531,6 +567,10 @@ static const struct iovec setup_data_no_location[] = {
 	/* ATT: Error Response */
 	IOV_DATA(0x01, 0x04, 0x0b, 0x00, 0x0a),
 	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x10, 0x00, 0x10, 0x00),
+	IOV_DATA(0x05, 0x01, 0x10, 0x00, 0x02, 0x29),
+	IOV_DATA(0x04, 0x13, 0x00, 0x13, 0x00),
+	IOV_DATA(0x05, 0x01, 0x13, 0x00, 0x02, 0x29),
 	IOV_DATA(0x04, 0x17, 0x00, 0x1a, 0x00),
 	/* ATT: Find Information Response (0x05): CCC */
 	IOV_DATA(0x05, 0x01, 0x17, 0x00, 0x02, 0x29),
@@ -551,6 +591,10 @@ static const struct iovec setup_data_no_location[] = {
 	 *   Handle range: 0x0001-0xffff
 	 *   Attribute type: Database Hash (0x2b2a)
 	 */
+	/* ATT: Find Information Request (0x04) */
+	IOV_DATA(0x04, 0x23, 0x00, 0x23, 0x00),
+	/* ATT: Find Information Response (0x05): CCC */
+	IOV_DATA(0x05, 0x01, 0x23, 0x00, 0x02, 0x29),
 	IOV_DATA(0x08, 0x01, 0x00, 0xff, 0xff, 0x2a, 0x2b),
 	/* ATT: Error Response (0x01) len 4
 	 *   Read By Type Request (0x08)
diff --git a/unit/test-mcp.c b/unit/test-mcp.c
index 6331c6c..e579c1e 100644
--- a/unit/test-mcp.c
+++ b/unit/test-mcp.c
@@ -264,7 +264,29 @@ static void test_teardown(const void *user_data)
 		FIND_CHRC(CP_SUPP+base, PROP_RN, 0xa5, 0x2b), \
 		FIND_CHRC(CCID+base, PROP_R, 0xba, 0x2b)), \
 	IOV_DATA(0x08, CCID+base, 0x00, CCID+base, 0x00, 0x03, 0x28), \
-	IOV_DATA(0x01, 0x08, CCID+base, 0x00, 0x0a)
+	IOV_DATA(0x01, 0x08, CCID+base, 0x00, 0x0a), \
+	IOV_DATA(0x04, HND(NAME_CCC), HND(NAME_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(NAME_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(TRACK_CHG_CCC), HND(TRACK_CHG_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(TRACK_CHG_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(TRACK_TITLE_CCC), HND(TRACK_TITLE_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(TRACK_TITLE_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(TRACK_DUR_CCC), HND(TRACK_DUR_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(TRACK_DUR_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(TRACK_POS_CCC), HND(TRACK_POS_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(TRACK_POS_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(PLAY_SPEED_CCC), HND(PLAY_SPEED_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(PLAY_SPEED_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(SEEK_SPEED_CCC), HND(SEEK_SPEED_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(SEEK_SPEED_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(PLAY_ORDER_CCC), HND(PLAY_ORDER_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(PLAY_ORDER_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(STATE_CCC), HND(STATE_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(STATE_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(CP_CCC), HND(CP_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(CP_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(CP_SUPP_CCC), HND(CP_SUPP_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(CP_SUPP_CCC), 0x02, 0x29)
 
 /* As above but without optional Notify properties, and
  * ATT: Find Information Request (0x04)
@@ -294,6 +316,8 @@ static void test_teardown(const void *user_data)
 	IOV_DATA(0x01, 0x08, CCID+base, 0x00, 0x0a), \
 	IOV_DATA(0x04, HND(NAME_CCC), HND(NAME_CCC)), \
 	IOV_DATA(0x01, 0x04, HND(NAME_CCC), 0x0a), \
+	IOV_DATA(0x04, HND(TRACK_CHG_CCC), HND(TRACK_CHG_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(TRACK_CHG_CCC), 0x02, 0x29), \
 	IOV_DATA(0x04, HND(TRACK_TITLE_CCC), HND(TRACK_TITLE_CCC)), \
 	IOV_DATA(0x01, 0x04, HND(TRACK_TITLE_CCC), 0x0a), \
 	IOV_DATA(0x04, HND(TRACK_DUR_CCC), HND(TRACK_DUR_CCC)), \
@@ -306,6 +330,10 @@ static void test_teardown(const void *user_data)
 	IOV_DATA(0x01, 0x04, HND(SEEK_SPEED_CCC), 0x0a), \
 	IOV_DATA(0x04, HND(PLAY_ORDER_CCC), HND(PLAY_ORDER_CCC)), \
 	IOV_DATA(0x01, 0x04, HND(PLAY_ORDER_CCC), 0x0a), \
+	IOV_DATA(0x04, HND(STATE_CCC), HND(STATE_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(STATE_CCC), 0x02, 0x29), \
+	IOV_DATA(0x04, HND(CP_CCC), HND(CP_CCC)), \
+	IOV_DATA(0x05, 0x01, HND(CP_CCC), 0x02, 0x29), \
 	IOV_DATA(0x04, HND(CP_SUPP_CCC), HND(CP_SUPP_CCC)), \
 	IOV_DATA(0x01, 0x04, HND(CP_SUPP_CCC), 0x0a)
 
diff --git a/unit/test-rap.c b/unit/test-rap.c
index d7da2ff..1eba012 100644
--- a/unit/test-rap.c
+++ b/unit/test-rap.c
@@ -585,21 +585,16 @@ static void test_client_rap(const void *user_data)
  *       Error: Attribute Not Found (0x0a)
  */
 #define RAS_FIND_INFO \
-	IOV_DATA(0x04, 0x06, 0x00, 0x12, 0x00), \
-	IOV_DATA(0x05, 0x01, \
-		0x06, 0x00, 0x02, 0x29, \
-		0x07, 0x00, 0x03, 0x28, \
-		0x08, 0x00, 0x16, 0x2c, \
-		0x09, 0x00, 0x02, 0x29, \
-		0x0a, 0x00, 0x03, 0x28, \
-		0x0b, 0x00, 0x17, 0x2c, \
-		0x0c, 0x00, 0x02, 0x29, \
-		0x0d, 0x00, 0x03, 0x28, \
-		0x0e, 0x00, 0x18, 0x2c, \
-		0x0f, 0x00, 0x02, 0x29, \
-		0x10, 0x00, 0x03, 0x28, \
-		0x11, 0x00, 0x19, 0x2c, \
-		0x12, 0x00, 0x02, 0x29), \
+	IOV_DATA(0x04, 0x06, 0x00, 0x06, 0x00), \
+	IOV_DATA(0x05, 0x01, 0x06, 0x00, 0x02, 0x29), \
+	IOV_DATA(0x04, 0x09, 0x00, 0x09, 0x00), \
+	IOV_DATA(0x05, 0x01, 0x09, 0x00, 0x02, 0x29), \
+	IOV_DATA(0x04, 0x0c, 0x00, 0x0c, 0x00), \
+	IOV_DATA(0x05, 0x01, 0x0c, 0x00, 0x02, 0x29), \
+	IOV_DATA(0x04, 0x0f, 0x00, 0x0f, 0x00), \
+	IOV_DATA(0x05, 0x01, 0x0f, 0x00, 0x02, 0x29), \
+	IOV_DATA(0x04, 0x12, 0x00, 0x12, 0x00), \
+	IOV_DATA(0x05, 0x01, 0x12, 0x00, 0x02, 0x29), \
 	IOV_DATA(0x04, 0x13, 0x00, 0x13, 0x00), \
 	IOV_DATA(0x01, 0x04, 0x13, 0x00, 0x0a)
 
-- 
2.39.5

RE: [v2] shared/gatt-client: discover the CCC descriptor instead of assuming it

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 988 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/project/bluetooth/list/?series=1142530

---Test result---

Test Summary:
CheckPatch                    PASS      0.41 seconds
GitLint                       PASS      0.25 seconds
BuildEll                      PASS      20.17 seconds
BluezMake                     PASS      532.41 seconds
MakeCheck                     PASS      19.72 seconds
MakeDistcheck                 PASS      152.93 seconds
CheckValgrind                 PASS      222.95 seconds
CheckSmatch                   PASS      294.26 seconds
bluezmakeextell               PASS      95.51 seconds
IncrementalBuild              PASS      532.08 seconds
ScanBuild                     PASS      864.11 seconds



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

---
Regards,
Linux Bluetooth