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

Proxy alt <[email protected]>
Newsgroups org.kernel.vger.linux-bluetooth
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.