Re: duplicate L2CAP connection requests - before and after L2CAP information response

[Marcel Holtmann <marcel@holtmann.org>]

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