Hi Artem, Marcel,
On Wed, Aug 27, 2014 at 9:33 AM, Artem Rakhov <arakhov@xxxxxxxxxxxx> wrote:
> On Tue, Aug 26, 2014 at 7:08 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>> Hi Artem,
>>
>>>>> please do not top post on this mailing list. It does break the reading thread.
>>>>>
>>>>>> Here is hcitool info:
>>>>>>
>>>>>> BD Address: 10:B7:F6:01:31:ED
>>>>>> Device Name: Monster Clarity
>>>>>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c
>>>>>> Manufacturer: Cambridge Silicon Radio (10)
>>>>>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>>>>>> <3-slot packets>
>>>>>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83
>>>>>>
>>>>>> Label also says Precision Micro Bluetooth Speaker 100.
>>>>>
>>>>> normally all CSR based solutions should just work. Maybe this is just a bad firmware. Are you sure that Connection Pending is really causing the observed problem. It sounds strange to hit that on a CSR based speaker.
>>>>
>>>> I compared the logs from avtest and bluetoothd (attached earlier in
>>>> this thread). I think the only difference that could matter is this
>>>> Authorization Pending response.
>>>
>>> I've tested several devices with and without Defer Setup feature enabled.
>>>
>>> Here is a list of devices, which successfully initiate A2DP
>>> connection, not depending on Defer Setup:
>>> Creative WP-350 Headset
>>> MiiKey Rythm
>>> JBL Micro Wireless
>>> HMDX Rave
>>> Plantronics BBfit
>>> Bose SoundLink Mobile speaker II
>>> SOL Tracks Air
>>> Sony MDR-1RBT
>>>
>>> Here is a list of devices, which fail to initiate A2DP connection with
>>> Defer Setup enabled, but work fine when Defer Setup is disabled:
>>> Monster Clarity HD
>>> Motorola S9-HD
>>> Sennheiser PX210
>>> 2010 Toyota Prius
>>
>> are all of these CSR based devices? If so then it sounds like a batch of broken CSR firmware. If not, then the L2CAP test cases might better be extended to have a test case for this. It is dangerous if such a fundamental Bluetooth 1.1 feature is not working correctly.
>
> Yes, all these devices are CSR-based.
Well I have access to none of those which is kind nice.
>>> There are no devices, which are working with Defer Setup, and not
>>> working without Defer Setup. So I didn't see any regression.
>>>
>>> As a result, 4 out of 12 devices do not connect as expected with Defer
>>> Setup enabled. I think we should consider disabling Defer Setup by
>>> default, at least for audio.
>>
>> I all cases this is the A2DP signaling channel that causes the problem? It is not the media channel that is required for streaming?
>
> Yes, exactly same scenario. The very first connection fails from
> speaker to source, which goes to AVDTP (PSM 25).
There are some other things to experiment, there seems to be possible
to use ERTM nowadays, for signalling only, and while this does not
exactly change in any way how we use authorization pending response it
perhaps make a difference in terms of timing, if we are lucky,
otherwise we can go with whitelist and retry.
>> Our real problem is that we need Defer Setup to be able to cleanly reject connections from devices that we do not know and do not want to talk to use. Especially if they are just not authorized to do so.
>>
>> Maybe we should use the proposal that Luiz had and just disconnect after a timeout and try to establish the connection from our side. That might actually be useful as a workaround. An alternative option is that we delay the connection pending message for some time and give userspace the chance to respond with either read() or close(). That way we would send the correct answer. However that timeout can only be really short since we need to keep the L2CAP signaling working correctly. So it would only work for cases where the daemon has all information to make a decision. If it asks the user, then this is off limits.
>>
>> That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that might be useful to mitigate this behavior as well. Unknown devices would be blocked on the ACL level already.
If whitelist for classic is to be based on the trusted list, which I
assume it should be, then the kernel could accept the connection right
away but then we need some mechanism to query if the whitelist has
taken effect or maybe it is fine already since bt_io_accept does the
following:
if (!(pfd.revents & POLLOUT)) {
if (read(sock, &c, 1) < 0) {
ERROR_FAILED(err, "read", errno);
return FALSE;
}
}
So POLLOUT seems to be for checking if the socket has been accepted
already, in case we have a older kernel we can only retry if
authorization succeeds but that will probably only happen if the
device happens to be trusted otherwise it will trigger the agent for
user to authorize and it more likely the device will disconnect before
the user can react cancelling the authorization.
--
Luiz Augusto von Dentz
--
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
