From: Proxy alt <proxy-alt@proxy-alt.dev>
To: linux-bluetooth@vger.kernel.org
Cc: luiz.dentz@gmail.com, Proxy alt <proxy-alt@proxy-alt.dev>
Subject: Re: [PATCH BlueZ] shared/gatt-client: discover the CCC descriptor instead of assuming it
Date: Sat, 8 Aug 2026 00:16:33 -0400 [thread overview]
Message-ID: <20260808041633.69337-1-proxy-alt@proxy-alt.dev> (raw)
In-Reply-To: <20260808031940.66686-1-proxy-alt@proxy-alt.dev>
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.
next prev parent reply other threads:[~2026-08-08 4:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 3:19 [PATCH BlueZ] shared/gatt-client: discover the CCC descriptor instead of assuming it Proxy alt
2026-08-08 4:16 ` Proxy alt [this message]
2026-08-08 4:34 ` [BlueZ] " bluez.test.bot
2026-08-08 4:45 ` [PATCH v2] " Proxy alt
2026-08-08 6:10 ` [v2] " bluez.test.bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260808041633.69337-1-proxy-alt@proxy-alt.dev \
--to=proxy-alt@proxy-alt.dev \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox