Return-Path: MIME-Version: 1.0 In-Reply-To: <1335164553.16897.371.camel@aeonflux> References: <1335004527.16897.337.camel@aeonflux> <1335035377.16897.340.camel@aeonflux> <1335042808.16897.350.camel@aeonflux> <1335125337.16897.357.camel@aeonflux> <1335130524.16897.365.camel@aeonflux> <20120422222246.GA27438@x220.P-661HNU-F1> <1335164553.16897.371.camel@aeonflux> Date: Mon, 23 Apr 2012 11:24:06 +0300 Message-ID: Subject: Re: PTS / linkkey issue From: Luiz Augusto von Dentz To: Marcel Holtmann Cc: Johan Hedberg , Mike , linux-bluetooth Content-Type: text/plain; charset=ISO-8859-1 List-ID: Hi Marcel, On Mon, Apr 23, 2012 at 10:02 AM, Marcel Holtmann wrote: > > I was considering that if pairing is allowed and security is either > medium or high, then we force a repairing if the link key is temporary. > > Something like in the area of a no bonding link key is only allowed to > connect a security low service. And if pairing is not allowed and you > try to access a medium or high security service with no bonding, you > will just get rejected. > But the reattempt could possible generate a no bonding again and if we just reject it might cause more IOP problems. @Mike: You can mark the device as non-temporary by calling Adapter.CreateDevice, bluetoothd will attempt to do another sdp browse but it should be fine for PTS as we do reversed sdp anyway when someone pair to us, I guess that would work as workaround for qualification but I wouldn't enable this behavior on production. -- Luiz Augusto von Dentz