mringwal
commented
7 months ago Hi Alessandro. Thanks for reporting and providing a stripped down example. That was a tricky one. It was a fairness issue: when there are more than one waiting SDP queries on a profile AND there was at least another waiting SDP query, the same connection would get preferred over and over. Fixed for A2DP/AVDTP and HFP on develop 478f65a. (we've also updated hid host, goep client and avrcp in a similar way)
Describe the bug
Scenario:
1 bonded smartphone 1 bonded headset
I'm trying to connect to both devices at startup (hfp/a2dp profiles). If connection fails, I just periodically retry to connect.
For example;
1) connect to smartphone hfp/hf; 2) connect to headset hfp/ag; 3) connect to smartphone a2dp/sink; 4) connect to headset a2dp/source;
These steps are executed sequentially. When connection fails (connections will always fail, since I'm keeping the devices powered off), I just retry to connect to that device/profile;
To Reproduce
example.txt (devices have been already bonded). Rename to example.c
After devices are bonded, keep them (smartphone/headset) powered off to replicate the issue.
Expected behavior
I would expect the following infinite loop
1) connect to smartphone hfp/hf -> timeout 2) connect to headset hfp/ag-> timeout 3) connect to smartphone a2dp/sink-> timeout 4) connect to headset a2dp/source -> timeout 5) restart from step 1
Observed behavior What I'm seeing, connection to smartphone is issued only once. From step 3), only headset will be try to be connected.
HCI Packet Logs HCI_log.txt (rename to HCI_log.pcap)
Environment: (please complete the following information):
Additional context I've tried to debug and I think there is something not managed correctly in sdp_client_register_query_callback (just my guess).