`ATT_ERROR_ATTRIBUTE_NOT_FOUND` when subscribing to notifications

[Aidan-McNay]

Describe the bug

Hi all! First off, thanks for the great library - super useful already!

I'm working on a PicoW, and have written an object to go through the discovery process of all characteristics/descriptors with a BLE connection as a client. However, when I then call gatt_client_write_client_characteristic_configuration to enable notifications, the corresponding GATT_EVENT_QUERY_COMPLETE GATT Event always has an ATT status of ATT_ERROR_ATTRIBUTE_NOT_FOUND. I've confirmed that the characteristic I'm using has the notify flag set in the properties, and from the debug output, it looks as though the value is initially found (?)

...
gatt_client.c.2131: ENABLE_GATT_FIND_INFORMATION_FOR_CCC_DISCOVERY, state 27
gatt_client.c.2140: CCC found 312
...

I'm still a little new at using GATT clients, so any insight would be appreciated!

To Reproduce

Reproduction is a little difficult, mostly because I'm specifically connecting to a blood pressure sensor for my project. You're more than welcome to check out the source code here; specifically, after I've discovered all the characteristics, I attempt to enable notifications here, and receive the event packet here. It's set up as a Pico project with the VSCode extension, and could be imported as such if it's useful

Expected behavior

I expect the GATT_EVENT_QUERY_COMPLETE packet to have an ATT status of 0 (ATT_ERROR_SUCCESS); however, it consistently has a status of 0xA (ATT_ERROR_ATTRIBUTE_NOT_FOUND)

HCI Packet Logs

ascii-log-file.pklg.zip

Environment: (please complete the following information):

• Current BTstack branch: 1.6.2 (from the Pico SDK 2.1.1)
• Bluetooth Controller Pico W
• Remote device: Omron Evolv Blood Pressure Monitor

[Aidan-McNay]

One other comment; when trying to debug, I used att_dump_attributes() to try and visualize the database. Interestingly, it didn't show up with any data - a.k.a. only dumped

att_db.c.267: att_dump_attributes, table 00000000

Not sure if this is expected for a client?

[mringwal]

One other comment; when trying to debug, I used att_dump_attributes() to try and visualize the database. Interestingly, it didn't show up with any data - a.k.a. only dumped

att_db.c.267: att_dump_attributes, table 00000000

Not sure if this is expected for a client?

That's expected, the att_dump_attributes only dumps the ATT DB of the local GATT Server.

[mringwal]

The packet log has no HCI packets. Please enable logging of packets and disable ENABLE_LOG_DEBUG.
Could you try to connect to our GATT Counter example which would simplify the verification?

[Aidan-McNay]

Thanks for the quick response! I've attached logs as you've described (both with and without my own debug output, not sure if it makes a difference). I'll also try the GATT counter over the weekend (just need to get my hands on another Pico, since I'm on a Mac). Is there anything else you might recommend in the meantime to debug/where the issue might come up? Thanks a lot!

omron-log-no-debug.pklg.zip

omron-log.pklg.zip

[mringwal]

Hi Aidan. If you open the logs, you see that there are requests for Attribute Handle 0x0000, which is certainly incorrect.

I would suggest to simplify the logic to subscribe to a single characteristic in a single service and then follow the log.
You can also use some other GATT Browser like LightBlue or nRF Toolkit on a smart phone to manually document the GATT DB on the Omron device and compare it to the results from BTstack (which should be the same).

You can run BTstack on macOS easily with an USB Bluetooth dongle, see port/libusb

[Aidan-McNay]

Ah, thanks for the help! Looks like I was mistakenly trying to enable reading on all attributes, not just those that supported it 😅. I fixed all of those issues; however, the problem remains. I've been using LightBlue to verify that my database is correct (and that enabling notifications on 0x311 is valid; LightBlue shows it with Notify as well)

One observation: Initially upon discovery, all attributes show a Rcvd Error Response - Attribute Not Found, Handle: ... in the packet log; I'm assuming this is expected? For this portion, I'm just following the le_streamer_client example (the same commands and whatnot). The other observation I had in the packet log (which I tried on repeat at the end) was that I would expect enabling notifications for 0x311 to only write 0x312, but it appears to also try and access 0x313 (shown below); not sure if this might be a cause? The difference now is if I try and repeat accesses to 0x313 (which I'd expect to work based on the others above), they all give the same error

(I would use a USB dongle, but unfortunately away from mine at the moment)

Thanks again for the help so far!

log.pklg.zip

[mringwal]

Hm. The log shows "CCC found 312", but then doesn't use the information to write to 312.
If you get the USB dongle, you could run the code on your Mac and follow the code in the debugger.
It's strange as that's a very basic feature. Could you try to switch to the current develop branch, too?

[Aidan-McNay]

Will try - I also found one other thing, which I think has to do with my characteristic end handles and a break being used in a while loop inside a case statement. Looking here:

btstack/src/ble/gatt_client.c

Lines 2131 to 2154 in 501e6d2

	log_info("ENABLE_GATT_FIND_INFORMATION_FOR_CCC_DISCOVERY, state %x", gatt_client->state);
	if (gatt_client->state == P_W4_FIND_CLIENT_CHARACTERISTIC_CONFIGURATION_QUERY_RESULT){
	// iterate over descriptors looking for CCC
	if (pair_size == 4){
	while ((offset + 4) <= size){
	uint16_t uuid16 = little_endian_read_16(packet, offset + 2);
	if (uuid16 == GATT_CLIENT_CHARACTERISTICS_CONFIGURATION){
	gatt_client->client_characteristic_configuration_handle = little_endian_read_16(packet, offset);
	gatt_client->state = P_W2_WRITE_CLIENT_CHARACTERISTIC_CONFIGURATION;
	log_info("CCC found %x", gatt_client->client_characteristic_configuration_handle);
	break;
	}
	offset += pair_size;
	}
	}
	if (is_query_done(gatt_client, last_descriptor_handle)){
	} else {
	// next
	gatt_client->start_group_handle = last_descriptor_handle + 1;
	gatt_client->state = P_W2_SEND_FIND_CLIENT_CHARACTERISTIC_CONFIGURATION_QUERY;
	}
	break;
	}

It looks as though is_query_done evaluates to false, causing the client to continue searching the handle range (which makes sense why it would start looking for 0x313 up instead of writing 0x312, as well as the previous Attribute Not Found errors). My wonder then is why the handle ranges are so long...if I look here when the handles are first returned:

It looks as though the end handle given in the packet is all 0's, and for some reason, this subsequently causes the search range later to be much larger (0x0012-0x001f, 0x0022-0x002f, etc.). Is it worth it to try and artificially decrease the end handle after the characteristic is received, or is there a better way to go about this?

I suppose I'm also confused why we'd want to search the entire handle range when writing a specific characteristic configuration, if the handle for that configuration is known. Perhaps the break is meant to break out of the larger case statement, and not just the inner while loop? This would also seem to explain why searching a handler range often continues, even when the data has already been found

[mringwal]

Fair question: when looking for "the" client characteristic configuration descriptor, the first one should be good.
Together with the point that the Characteristics have more attributes than usual, this might actually be a bug.
We'll have a look into this next week.

For testing, you can artificially tweak the characteristic, the CCCD is usually the handle after the value handle, so you could set end handle = value handle + 1 to see if that works - please let me know

[Aidan-McNay]

(Assuming the break is meant to break out of the larger case statement, and not just the while loop, I'd be happy to submit a PR if it's useful :) )

[mringwal]

You might be right about the break. Will have a look at it on Monday (no need for a PR).

[Aidan-McNay]

Artificially limiting the handle range (end_handle = value_handle + 1) to prevent the extra iterations appears to have worked - thanks for the help :)

[mringwal]

Hi Aidan. Could you try the fix on the develop branch for this? It only changes the break into a return (as you might have suggested)?