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 ;)
I can reproduce this with
l2test -n ADDRESS
The two devices need to be paired first. Here was the hcidump I got
from this repro. This time it was the remote features response that
triggered the duplicate l2cap connection request. I assume it is the
same l2cap_conn_start() path after the feature response that triggers
the duplicate.
I can also repro this connecting to many A2DP headsets, but most
remote stacks seem to be tolerant of our mistake and let it go. I
guess PTS comes in handy sometimes :)
are you actually using a plain 2.6.27 kernel or do you have patched
out the L2CAP info stuff. I don't see us sending the requests for that
and this might screw up the state machine.
And please just verify this against bluetooth-testing.git without any
other core Bluetooth patches. I really don't see how we end up in your
code path except your code is modified.
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
