MIME-Version: 1.0
References: <87ee5fc2175747e1a7cf5b50bad819d4@ausx13mpc124.AMER.DELL.COM>
 <CAO1O6seYhTMHrgCQ+9gPCo_UOtXfhh9mRCVoUosP_Eq0FXD=sw@mail.gmail.com> <bcaa44382c80428ba59b743678be0b18@ausx13mpc120.AMER.DELL.COM>
In-Reply-To: <bcaa44382c80428ba59b743678be0b18@ausx13mpc120.AMER.DELL.COM>
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Fri, 12 Apr 2019 00:03:00 +0200
Message-ID: <CAO1O6sebmS8P0EVVL=U+eFFq+u0NdtbHUP0dO1D+LPa4vXOWqg@mail.gmail.com>
Subject: Re: Pairing failure with BLE 4.0
To:     YouRen.Chen@dellteam.com,
        Bluez mailing list <linux-bluetooth@vger.kernel.org>
Cc:     Jared.Dominguez@dell.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi You Ren,

Den ons 10 apr. 2019 kl 20:43 skrev <YouRen.Chen@dellteam.com>:
>
> Hello Emil,
>
> > Hi YouRen,
> >
> > Den tis 9 apr. 2019 kl 22:31 skrev <YouRen.Chen@dellteam.com>:
> > >
> > > Hello,
> > >
> > > Recently, I posted a bug report regarding authentication failures when
> > > pairing with BLE 4.0 devices. I was told to raise this issued to the
> > > Bluetooth mailing lists and I hope this is the correct email to contact.
> > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822633
> >
> > Could you please also post the HCI log?
> > In a terminal window, execute "sudo btmon" to start logging. Then try to pair
> > your device (reproduce the issue). The btmon tool should now have printed
> > the HCI packets to stdout.
> >
> > /Emil
>
> I have attached a .snoop file from when I attempted to pair the BLE device, would this be acceptable?

I looked at the log in Wireshark. To summarise it, BlueZ sends a
Pairing Request SMP packet (opcode 0x01):

IO Capability: Keyboard, Display (0x04)
OOB Data Flags: OOB Auth. Data Not Present (0x00)
AuthReq: 0x2d, CT2 Flag, Secure Connection Flag, MITM Flag, Bonding
Flags: Bonding
Max Encryption Key Size: 16
Initiator Key Distribution: 0x0d, Link Key, Signature Key (CSRK),
Encryption Key (LTK)
Responder Key Distribution: 0x0f, Link Key, Signature Key (CSRK),
Encryption Key (LTK)

The peripheral device then sends a Pairing Failed SMP packet (opcode
0x05) containing "Invalid Parameters (0x0a)" as result. The link is
then disconnected due to the failure.

It's clear that the pen misbehaves since it sends Invalid Parameters
as response even though BlueZ indeed sends valid parameters.

Anyway, looking at
https://launchstudio.bluetooth.com/ListingDetails/490, it's clear that
the pen PN557W uses a DA14580 chip, which has a Riviera Waves
Bluetooth stack. Unfortunately I know that this stack contains a bug.
Since it was made for a Bluetooth spec earlier than 4.2, there are
five bits in the Key Distribution fields that are reserved for future
use. Per the 4.0 spec, "Reserved is a 5-bit field that shall be set to
zero and ignored on reception." This bluetooth stack does not follow
this but instead sends a Pairing Failed result with Invalid Parameters
as error code when any bit is nonzero. One of those bits got used in
the 4.2 spec and it's called LinkKey which is a bitfield that's set to
1 if the Link Key (used for Bluetooth classic pairing) should be
derived from the BLE key if the two devices some time in the future
would communicate using Bluetooth Classic. Now of course the pen
doesn't support Bluetooth Classic (that can be seen by looking at the
flags in the advertising data). I reported this bug to the company
making DA14580 more than three years ago and they released a patch
short time thereafter which is included in their latest SDKs.

It seems like Dell neither used the latest DA14580 SDK when the
firmware was written (looking at the publish date of 2016-08-31 in the
Bluetooth listings) nor has released a firmware update for it (since I
assume you have installed it if you there was a newer one?).

Could you try remove these two lines at
https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L693
to see if it works (also make sure by looking at the log later that
those bits were not set in the Key Distribution field)?:
local_dist |= SMP_DIST_LINK_KEY;
remote_dist |= SMP_DIST_LINK_KEY;

We have seen the exact same problem when Android 6 was released.
However they have a workaround that they don't set the LinkKey bit if
they suspect the device doesn't support it. I think they look at the
advertising data which indicates in the flags that it doesn't support
BR/EDR. I think BlueZ should do the same to workaround these
incompatibility issues.

/Emil