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

[Peter Hurley <peter@hurleysoftware.com>]

Hi Daniel & Johan,

On Wed, 2012-01-11 at 06:26 -0500, Johan Hedberg wrote:
> Hi Daniel,
> 
> On Mon, Jan 09, 2012, Daniel Wagner wrote:
> > Hi Johan,
> > 
> > On 04.01.2012 11:22, Daniel Wagner wrote:
> > > Hi Peter,
> > > 
> > > On 09.08.2011 22:26, Peter Hurley wrote:
> > >> Commit 330605423c fixed l2cap conn establishment for non-ssp remote
> > >> devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
> > >> is tested (which was always returning failure on any subsequent
> > >> security checks).
> > >>
> > >> However, this broke l2cap conn establishment for ssp remote devices
> > >> when an ACL link was already established at SDP-level security. This
> > >> fix ensures that encryption must be pending whenever authentication
> > >> is also pending.
> > >>
> > >> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> > > 
> > > git am complaines:
> > > 
> > > Applying: Bluetooth: Fix l2cap conn failures for ssp devices
> > > /home/wagi/src/bluetooth-next/.git/rebase-apply/patch:18: trailing whitespace.
> > > 
> > > /home/wagi/src/bluetooth-next/.git/rebase-apply/patch:19: trailing whitespace.
> > >                 /* encrypt must be pending if auth is also pending */
> > > /home/wagi/src/bluetooth-next/.git/rebase-apply/patch:20: trailing whitespace.
> > >                 set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend);
> > > /home/wagi/src/bluetooth-next/.git/rebase-apply/patch:21: trailing whitespace.
> > > 
> > > 
> > > But it fixes the problem I was debugging. From what I have
> > > learned in the last two days I would say it is also the right fix :)
> > 
> > Is there any chance to get this patch in? If it helps I could send a
> > whitespace fixed version.
> 
> Feel free to send a whitespace-fixed version, but even then I only apply
> patches with Marcel's ack on them. Btw, have you verified that this
> doesn't break non-SSP cases? Is this how the code used to behave before
> the regression?
> 
> Johan

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.

Regards,
Peter Hurley