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. > 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? 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. 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
