Return-Path: Message-ID: <1335164553.16897.371.camel@aeonflux> Subject: Re: PTS / linkkey issue From: Marcel Holtmann To: Johan Hedberg Cc: Mike , linux-bluetooth Date: Mon, 23 Apr 2012 09:02:33 +0200 In-Reply-To: <20120422222246.GA27438@x220.P-661HNU-F1> 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Johan, > > the real problem that you are seeing here is that the disappearing of > > the BlueZ devices and with that the oFono modem is actually fully > > intentional. It boils all down to the no bonding pairing. The device > > never gets marked as bonded. > > > > I honestly have no idea on how to workaround this issue. My only idea is > > that we combine the access to a RFCOMM server channel with a re-pairing > > to upgrade this to general bonding. Problem is just that I have no idea > > if this would fly with the GAP qualification or not. Or if we would > > break that one then. > > This whole thing looks so obviously as a PTS issue to me that I don't > see why anyone should spend any effort on anything else than raising an > errata for the PTS. > > As far as what you're suggesting as a potential workaround it still > wouldn't guarantee that the PTS would start giving an authentication > requirement other than no-bonding. We can only control our own > authentication requirement. > > Furthermore, you couldn't have this as general RFCOMM server behavior > since there are servers for which no-bonding may be desirable, like OPP, > and clients might not be tested to handle rejecting our general bonding > request properly if they were designed to assume they can get by with > their initial no-bonding request. 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. Regards Marcel