Skip to content

Error in retrieveDescriptors() during subscribe #395

Closed

Description

@gkoh

Version: 2.3.4

I updated from 2.3.2 to 2.3.4 and one of my target devices fails during a subscribe with:

E (16166) NimBLERemoteCharacteristic: ble_gattc_disc_all_dscs: rc=3 One or more arguments are invalid

So, I dutifully hacked in some debug to dump the arguments:

...
E (15958) NimBLERemoteCharacteristic: 1 = 0, 2 = 77, 3 = 83, 4 = 0x4011e454, 5 = 0x3ffd9bb4
...
E (16158) NimBLERemoteCharacteristic: 1 = 0, 2 = 82, 3 = 76, 4 = 0x4011e454, 5 = 0x3ffd9bb4
E (16166) NimBLERemoteCharacteristic: ble_gattc_disc_all_dscs: rc=3 One or more arguments are invalid

Note that argument 2, the handle, is now beyond the 'end handle' returned by getRemoteService()->getEndHandle() and the end handle has changed.
The usage pattern is:

  • pChr1 = pSvc->getCharacteristic(UUID1);
  • pChr2 = pSvc->getCharacteristic(UUID2);
  • pChr2->subscribe(UUID2A);
  • pChr1->subscribe(UUID1A);

As this was working before, I backed up to 2.3.3 and got this output:

...
E (18026) NimBLERemoteCharacteristic: 1 = 0, 2 = 77, 3 = 83, 4 = 0x4011e3c4, 5 = 0x3ffd9c24
...
E (18227) NimBLERemoteCharacteristic: 1 = 0, 2 = 82, 3 = 83, 4 = 0x4011e3c4, 5 = 0x3ffd9c24

Note the end handle has not changed as before in the failure case.

I didn't bisect to confirm, but I'm fairly sure this is caused by #387.

Activity

  1. changed the title [-]Error in attribute discovery[/-] [+]Error in retrieveDescriptors() during subscribe[/+] on Feb 19, 2026
  2. gkoh commented on Feb 19, 2026

    @gkoh
    ContributorAuthor

    After poking around, I hacked a bit more and looks like the iteration loop to establish the end handle is getting limited:

    E (18654) NimBLERemoteCharacteristic: Search range limited to handle 0x004C
    

    (I couldn't work out which combination of LOG to up to debug, so I just hacked it to ERROR ...)

  3. h2zero commented on Mar 18, 2026

    @h2zero
    Owner

    @gkoh Is this still an issue?

  4. gkoh commented on Mar 26, 2026

    @gkoh
    ContributorAuthor

    @gkoh Is this still an issue?

    Just retested with 2.4.0.
    Yes, this is still an issue, let me know what I can add to help narrow this down (is it just me?).

  5. h2zero commented on Mar 27, 2026

    @h2zero
    Owner

    If you'd like to take a stab at finding this I'd appreciate it, otherwise I'll see what I can do after I get some other tweaks finished.

  6. gkoh commented on Mar 27, 2026

    @gkoh
    ContributorAuthor

    I'll give it a bash, if nothing else I should be able to gather more info for debug.

  7. gkoh commented on Mar 28, 2026

    @gkoh
    ContributorAuthor

    Caveat: I have approximately 0 knowledge of the hierarchy of characteristics and descriptors.

    I added more handle debug:

    E (12553) NimBLERemoteCharacteristic: >> retrieveDescriptors() for characteristic: 00002084-3dd4-4255-8d62-6dc7b9bd5561
    E (12554) NimBLERemoteCharacteristic: this->getHandle() = 77, endHandle = 83
    E (12562) NimBLERemoteCharacteristic: (*it)->getHandle() = 82
    E (12568) NimBLERemoteCharacteristic: (*it)->getHandle() = 77
    E (12575) NimBLERemoteCharacteristic: getConnHandle() = 0, getHandle() = 77, endHandle = 83
    I (12584) NimBLE: GATT procedure initiated: discover all descriptors; 
    I (12591) NimBLE: chr_val_handle=77 end_handle=83
    
    I (12653) NimBLE: GATT procedure initiated: write; 
    I (12654) NimBLE: att_handle=78 len=2
    
    E (12754) NimBLERemoteCharacteristic: >> retrieveDescriptors() for characteristic: 00002087-3dd4-4255-8d62-6dc7b9bd5561
    E (12764) NimBLERemoteCharacteristic: this->getHandle() = 82, endHandle = 83
    E (12772) NimBLERemoteCharacteristic: (*it)->getHandle() = 82
    E (12778) NimBLERemoteCharacteristic: Search range limited to handle 0x004C
    E (12786) NimBLERemoteCharacteristic: getConnHandle() = 0, getHandle() = 82, endHandle = 76
    

    As noted prior, my app attempts to subscribe to two characteristics, serially.
    From the above, it looks to me like the loop assumes the handles in the descriptor vector are numerically sorted.

    The first subscribe shows the iterator loops through handles in the order '82, 77'.
    On the second subscribe, it hits the end, but since the 'next' characteristic has a lower handle range, the 'next - 1' approach results in endHandle less than getHandle().

  8. gkoh commented on Mar 29, 2026

    @gkoh
    ContributorAuthor

    Can confirm, #415 fixes this.
    Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions