Return-Path: MIME-Version: 1.0 Sender: arakhov@google.com In-Reply-To: <3F6C8060-4B6F-4F18-A0D1-15B6CD7CE512@holtmann.org> References: <574DE1E1-7A53-4629-88FC-7164EC1880AA@holtmann.org> <2EF4B6C6-2375-45B7-B1AF-D30C4799AC93@holtmann.org> <2854D296-3CCA-4628-90B5-76D03EF2660D@holtmann.org> <3775CFA8-F840-440C-AC0E-FC639F542AA6@holtmann.org> <3F6C8060-4B6F-4F18-A0D1-15B6CD7CE512@holtmann.org> Date: Tue, 26 Aug 2014 23:33:17 -0700 Message-ID: Subject: Re: [A2DP] Incoming connections do not succeed From: Artem Rakhov To: Marcel Holtmann Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" , "Gustavo F. Padovan" Content-Type: text/plain; charset=UTF-8 List-ID: On Tue, Aug 26, 2014 at 7:08 PM, Marcel Holtmann wrot= e: > 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 exte= nded to have a test case for this. It is dangerous if such a fundamental Bl= uetooth 1.1 feature is not working correctly. Yes, all these devices are CSR-based. >> 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? I= t 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). > 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 us= e. 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 act= ually 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 a= nswer. 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 wher= e the daemon has all information to make a decision. If it asks the user, t= hen this is off limits. > > That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that m= ight be useful to mitigate this behavior as well. Unknown devices would be = blocked on the ACL level already. > > Regards > > Marcel > Thanks, Artem