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. > > We have not patched the L2CAP info stuff. In fact we are very close to > plain 2.6.27, the only significant BT patches we have are > pause-rfcomm-on-encryption-dropped which is also on > bluetooth-testing.git. > > Also, you'll notice that in my second hcidump, the problem occurred > after the remote features response, not the l2cap info response. So > i'm not sure that the code paths that cause this are specific to the > L2CAP info response. It seems to be any time that we hit > l2cap_conn_start() after already sending the request once. the problem is that even the L2CAP info request should not be sent before the features response (in case of 2.1 extended features response). I think your kernel is wrongly patched. Don't cherry-pick patches that you don't know the impact of. > > 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. > > Were you able to repo using bluetooth-testing.git? Just run it on my Quad G5 against my iPhone. It does work perfectly fine and that is even what the code review showed me. 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
