Re: [PATCH v3] Bluetooth: Fix l2cap conn failures for ssp devices

[Peter Hurley <peter@hurleysoftware.com>]

Hi Johan,

On Tue, 2012-01-17 at 03:27 -0500, Johan Hedberg wrote:
> Hi Peter,
> 
> On Mon, Jan 16, 2012, Peter Hurley wrote:
> > The situation with this patch is that I asked Gustavo not to apply it
> > (via IRC). Although the patch works, the overall logic of the
> > auth/encryption system is flawed.
> > 
> > With respect to this issue specifically (ie, ssp vs. non-ssp auth +
> > encrypt), the flaw is that the semantic meaning of the
> > HCI_CONN_ENCRYPT_PEND bit is overloaded. The meaning of one sense is
> > that an actual HCI_OP_SET_CONN_ENCRYPT command is in-flight, and thus,
> > for this hci connection, neither an auth nor encrypt request should be
> > sent. The second meaning is that the event handler *should* submit an
> > encrypt request upon receiving a successful auth complete event.
> > 
> > At the time, I had a patch prepared which addressed this duality as part
> > of a series which enabled true re-auth & sec_level promotion.
> > Unfortunately, I discovered that a prior patch had been submitted and
> > applied which specifically disables sec_level promotion for non-ssp
> > devices. The ml conversation died here
> > http://marc.info/?l=linux-bluetooth&m=131609282919575&w=2 so I dropped
> > it.
> 
> I think it'd be important to continue with this work. Even for
> controllers that don't allow a "security upgrade" you can still detect
> the situation when you get an auth_complete without any preceding
> link_key or PIN request and just drop the connection in such a case. For
> legacy pairing this would only happen when going from MEDIUM to HIGH
> since LOW means that you don't have a link key yet.
> 
> Btw, could you tell me the commit id of this "patch which specifically
> disables sec_level promotion for non-ssp devices"?

19f8def Bluetooth: Fix auth_complete_evt for legacy units

Peter