-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ATT Notification buffer not released after reconnection #47649
Comments
@carlst thanks for reporting. Is this a regression? Or you haven't tried older Zephyr versions? |
I have not tried older Zephyr versions. I have reviewed parts of the |
I added further logging to The added log entries (see Please let me know if I can provide any further information. |
Yes, most likely missing a call to |
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
@carlst I'm having some trouble reproducing it, do you mind uploading the Also, do you do anything on (re)connection before sending the notifications ? e.g. MTU exchange, encryption, stuff like that. |
@jori-nordic Uploaded as config_zephyr.log to (to avoid OS and browser limitations). Let me know if you need anything else. Yes, the issue is difficult to reproduce. It requires Notification data to be in flight when a disconnect occurs. i.e. data is handed over from ATT/L2CAP buffer to Bluetooth host but network buffer(s) not fully sent. Using long Notifications (e.g. 150 bytes) with short LL data lengths (e.g. default of 27) seems to help trigger it (multiple transfers during connection event). To increase odds, I also run with the external antenna of the sender disconnected so the signal is very weak. Upon connection, there is a request to change the MTU (to 512). No encryption. The peripheral also makes a Connection Parameter Update Request over the L2CAP signaling channel, but only after the connection exists for ~5 seconds. |
@carlst thanks to the config, I think I managed to reproduce it (using babblesim, which is pretty neat btw) here: main...jori-nordic:zephyr:att-buffer-leak . I opened a proper PR to fix it. Thanks for the bug report ! edit: just thought about it, could you try to reproduce your issue with the patch from #48395 applied ? Then you can add a comment to the PR directly if that really fixes the issue. |
@jori-nordic I can no longer reproduce the issue with #48395 applied. And I verified the patch code was called (and the in-flight buffer freed by ATT). A nice, clean fix. Babblesim is indeed quite good; I have not used it much where timing is important but may do so in the future. |
Symptoms were that a disconnect happening when a buffer was enqueued but not sent resulted in a meta-data memory leak. This is problematic because it seemed (as per the OP) that it resulted in the whole host getting locked up when a device sending long L2CAP packets was prone to disconnect-reconnect cycles (e.g. in a bad RF environment). Fixes zephyrproject-rtos#47649 Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Symptoms were that a disconnect happening when a buffer was enqueued but not sent resulted in a meta-data memory leak. This is problematic because it seemed (as per the OP) that it resulted in the whole host getting locked up when a device sending long L2CAP packets was prone to disconnect-reconnect cycles (e.g. in a bad RF environment). Fixes #47649 Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Symptoms were that a disconnect happening when a buffer was enqueued but not sent resulted in a meta-data memory leak. This is problematic because it seemed (as per the OP) that it resulted in the whole host getting locked up when a device sending long L2CAP packets was prone to disconnect-reconnect cycles (e.g. in a bad RF environment). Fixes zephyrproject-rtos#47649 Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Symptoms were that a disconnect happening when a buffer was enqueued but not sent resulted in a meta-data memory leak. This is problematic because it seemed (as per the OP) that it resulted in the whole host getting locked up when a device sending long L2CAP packets was prone to disconnect-reconnect cycles (e.g. in a bad RF environment). Fixes #47649 Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no> (cherry picked from commit 00709e5)
Describe the bug
A buffer allocated by Bluetooth ATT (and passed on to conn) but not yet sent when a disconnect occurs is never freed.
Please also mention any information which could help others to understand
the problem you're facing:
-Added BT_DBG messages to tx_meta_data_alloc and tx_meta_data_free to track buffer allocation count
To Reproduce
The issue occurs on a custom application which is sending several Notifications per second in an environment where disconnects occur every few minutes (perhaps electrically noisy environment).
Expected behavior
Either the buffer should be freed upon disconnect, or else freed after reconnect and send operation.
Impact
Annoyance. Workaround is currently to reboot system on disconnect.
Logs and console output
In boflo2.log, the first 2 disconnects occur when no Notification data is pending. In this case the buffer alloc and free counts are either 0 or 1 as expected (see log lines after 'Client MTU 512'). Subsequent 2 disconnects occur when Notification data is pending. In these cases, the buffer alloc count increases.
In boflo3.log (after more disconnects), the system eventually hangs (no response to ATT Client MTU request).
Environment (please complete the following information):
boflo2.log
boflo3.log
The text was updated successfully, but these errors were encountered: