Hi Nick,
We've noticed In some situations Bluez will send duplicate L2CAP connection requests. - Both are due to the same userspace connect() call, and have the same PSM and SCID, but different identifier. So the remote stack cannot send duplicate response because of different identifiers. - The first occurs before receiving L2CAP info response, and the second after due to the l2cap_information_rsp() -> l2cap_conn_start() code path. We are able to reproduce this consistently with basically any A2DP PTS test case. It only happens when the test case is started when already paired. This causes the PTS test case to fail because the tester rejects the second L2CAP request (resource unavailable). We are using 2.6.27. I looked at l2cap.c in bluetooth-testing.git and believe it will have the same issue. Question: to fix, which connection request should be removed?
can you write a small test case for this or use l2test to reproduce it. If so, then I might be able to fix this quickly. I have currently no clue why this happens and funny part of that is that we did pass all the BITE test cases ;)
Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
