Hi, On Wed, May 4, 2011 at 10:53 AM, <Lukasz.Rymanowski@xxxxxxxxx> wrote: > On Thu, Apr 28, 2011 at 12:39:37PM +0300, Antti Julku wrote: >> It's easy to reproduce at least with these dongles: >> >> Alink BLUEUSB21 (BCM) >> Belkin BT2.1 F8T017 (BCM) >> DeLock 2.1 (CSR) >> PTS 2.1 (CSR) >> >> So most of our BT 2.1 dongles seem to be buggy. It would be nice to >> have a workaround since it happens with so many dongles. > > If there is so many buggy devices I think Gustavo and Marcel could consider to take this patch. > > On 04/28/2011 12:51 PM, ext Ville Tervo wrote: >> Could the actual reason be some change in usb stack? Could it have >> lower priority for event pipe than for data pipe? In that case event >> for security change might arrive to bt stack too late. >> >> At lest I haven't seen this kind of behaviour with serial attached >> chips. So I think this is something USB specific. > > I found the problem on serial attached chip. > Before I received fix in the chip I used that patch for couple months without the problems. I guess it worth checking if there is some priority inversion like Ville suggested or it could be somehow related to RFCOMM, not long ago I fixed a bug to the security level of the rfcomm socket to be applied also to l2cap maybe it affects this. Another thing that I noticed is that this check for psm 1 may be to strict, there could be situation where an application want to BT_SECURITY_SDP on some arbitrary/non-reserved psm, which currently is possible with psm 3 (RFCOMM) since it only checks for sec.level > BT_SECURITY_HIGH (see rfcomm_sock_setsockopt:710, bug?), but it can't because of this security block will prevent any connection attempt. -- Luiz Augusto von Dentz Computer Engineer -- 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
