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

[Johan Hedberg <johan.hedberg@gmail.com>]

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"?

Johan