btmgmt_sync.send('LoadLinkKeys', ...) does not return...

[antoniovazquezblanco]

When using btmgmt_sync.send('LoadLinkKeys', ...), the function does not return...

Log details:

2024-07-01 15:34:40,926 - btsocket.btmgmt_protocol - DEBUG - Socket read <event_code=CommandCompleteEvent, controller_idx=0, param_len=3> <command_opcode=LoadLinkKeys, status=Success>
2024-07-01 15:34:40,926 - btsocket.btmgmt_sync - DEBUG - Received btmgmt frames: Response(header=<event_code=CommandCompleteEvent, controller_idx=0, param_len=3>, event_frame=<command_opcode=LoadLinkKeys, status=Success>, cmd_response_frame=None)

A response is received but the function keps calling recv...

[ukBaz]

This is because the code is in while loop checking that the cmd_response_frame has some content. However, the debug logging you have above has the value of cmd_response_frame=None so it will never exit.

This suggests to me either the logic in the send command is wrong or the response is not interrupted correctly.

I suspect some better logic to decide it has got a response is needed. However, there isn't enough test coverage to be highly confident what that logic should be.
Any thoughts?

[ukBaz]

Looking at the API documentation it looks like the current logic of testing for the cmd_response_frame to be not None will get stuck in the loop even if they are successful:

Load Link Keys Command
Load Long Term Keys Command
Set IO Capability Command
Set Scan Parameters Command
Load Identity Resolving Keys Command
Load Connection Parameters Command
Set Appearance Command
Set PHY Configuration Command
Load Blocked Keys Command
Set Default System Configuration Command
Set Default Runtime Configuration Command

This is because they are not expected to have any returned parameters.

[antoniovazquezblanco]

That makes sense to me. It seems a bug in the logic of the send comand that gets into an infinite loop due to missing returned parameters that should not be expected... :)