Bluetooth library corruption on notify of too small buffer from BLE LL_LENGTH_REQ, and other issues relating to monitoring those buffer sizes

Question

Hi,

I am developing a peripheral, and connecting to it with the nRF Connect phone app.

I have several issues relating to the max rx/tx parameters of LL_LENGTH_REQ and the library functionality.

Problem 1

When the peripheral gets the 'connected' callback, I look at the connection info for the phone's max rx/tx numbers.

At that moment, they are both 27 and 27.

However, looking at the snooped traffic:

I see the master did send LL_LENGTH_REQ, specifying its max rx/tx numbers (251/27)
I see myself reply with my numbers (27/27)

I never get a callback for the phone's updated numbers even though I'm registered for the le_data_len_updated callback the entire time.

If I later (eg a few min later) issue an LL_LENGTH_REQ via bt_conn_le_data_len_update(tx_max_len=251):

I see myself advertise my numbers (251/251) in the snoop
The phone replies with the exact same numbers it did the first time (251/27)
I do get a callback (I check parameters via bt_conn_get_info)

Questions:

Why am I not getting a callback in the first place?
1. Seemingly some part of your code knows the Phone's parameters, because it increased my RX numbers
Why are my initial response numbers so low? I have used the following prj.conf parameters, I would expect by default my response numbers to be 251.

# devzone.nordicsemi.com/.../increasing-ble-mtu-data-length-for-notifications-on-ncs-v1-8

CONFIG_BT_BUF_ACL_RX_SIZE=251

CONFIG_BT_BUF_ACL_TX_SIZE=251

CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

I have attached a wireshark capture for this problem.

problem1.pcapng

Problem 2

If I send LL_LENGTH_REQ before the phone has a chance to, I see in the snoop:

I advertise 251/251
The phone replies with rx=251/tx=27

However, I get a callback, and it says the phone has rx=27/tx=251 (flipped).

I also notice:

My (first) advertised numbers are 251/251 (unlike my problem 1)
My subsequent advertised numbers are 251/251
- But that shouldn't be, because your code checks to ensure I'm requesting different numbers than the ones in effect already
  - Implying that when I requested 251, they had been changed to something else locally already
  - Which is consistent with a suspected library issue of problem 1

Questions:

Why is this happening and what is the expected right behavior?
How can I read my own local rx/tx params at any given time?

I have attached a wireshark capture for this problem.

problem2.pcapng

Problem 3

The library breaks if I bt_gatt_notify(null, attr, buf, bufLen) where the bufLen is greater than the receive size of a connected Central (the phone).

It breaks in the sense that advertising stops functioning even though I never told it to stop. I have no idea what other internals are broken.

I get a return code of -128 and the following printed to the console (for a 200 byte bufLen).

[00:02:10.777,648] <wrn> bt_att: bt_att_create_pdu: No ATT channel for MTU 203
[00:02:10.898,590] <wrn> bt_gatt: gatt_notify: No buffer available to send notification

Even re-starting advertising at that point does not resume advertising. The device must be rebooted.

Question - What is the right way to use your API to avoid fatal issues like this when notifying?

Summary

I'm trying, ultimately, to avoid having a fatal hang like problem 3. I was tracking the smallest connected buffer size, only to learn that isn't reliable either.

This is the nrfconnect 3.11.1 package building under WSL Ubuntu built via the VSCode nRF Connect extension.

Thanks.