Determining whether a Bluetooth device supports pairing

Determining whether a Bluetooth device supports pairing

[John Keeping]

Hi,

I have a BLE MIDI keyboard which does not support pairing, and so far as
I can tell there is no way to determine this via the BlueZ DBus API.

If I try to pair I get the following hcidump trace which does indicate
that the device doesn't support pairing:

-- >8 --
< ACL data: handle 64 flags 0x00 dlen 11
    SMP: Pairing Request (0x01)
      capability 0x03 oob 0x00 auth req 0x09
      max key size 0x10 init key dist 0x0d resp key dist 0x0f
      Capability: NoInputNoOutput (OOB data not present)
      Authentication: Bonding (No MITM Protection)
      Initiator Key Distribution:  LTK  CSRK
      Responder Key Distribution:  LTK IRK CSRK
> ACL data: handle 64 flags 0x02 dlen 6
    SMP: Pairing Failed (0x05)
      reason 0x05
      Reason Pairing Not Supported
< HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 64 reason 0x05
    Reason: Authentication Failure
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 64 packets 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x16
    Reason: Connection Terminated by Local Host
-- 8< --

It seems that if pairing fails, the kernel disconnects from the device
and the DBus method returns AuthenticationFailed, but I can't see any
way to figure out whether or not a device supports pairing without
trying to pair with it.

Am I missing some method for determining whether or not a device
supports pairing?  Or do we need to handle SMP_PAIRING_NOTSUPP
specially?

I'm happy to work up some patches if the latter, but I'd like to make
sure I'm heading in a sensible direction before starting on that!


Thanks,
John

Re: Determining whether a Bluetooth device supports pairing

[Marcel Holtmann]

Hi John,

> I have a BLE MIDI keyboard which does not support pairing, and so far as
> I can tell there is no way to determine this via the BlueZ DBus API.
> 
> If I try to pair I get the following hcidump trace which does indicate
> that the device doesn't support pairing:
> 
> -- >8 --
> < ACL data: handle 64 flags 0x00 dlen 11
>    SMP: Pairing Request (0x01)
>      capability 0x03 oob 0x00 auth req 0x09
>      max key size 0x10 init key dist 0x0d resp key dist 0x0f
>      Capability: NoInputNoOutput (OOB data not present)
>      Authentication: Bonding (No MITM Protection)
>      Initiator Key Distribution:  LTK  CSRK
>      Responder Key Distribution:  LTK IRK CSRK
>> ACL data: handle 64 flags 0x02 dlen 6
>    SMP: Pairing Failed (0x05)
>      reason 0x05
>      Reason Pairing Not Supported
> < HCI Command: Disconnect (0x01|0x0006) plen 3
>    handle 64 reason 0x05
>    Reason: Authentication Failure
>> HCI Event: Command Status (0x0f) plen 4
>    Disconnect (0x01|0x0006) status 0x00 ncmd 1
>> HCI Event: Number of Completed Packets (0x13) plen 5
>    handle 64 packets 1
>> HCI Event: Disconn Complete (0x05) plen 4
>    status 0x00 handle 64 reason 0x16
>    Reason: Connection Terminated by Local Host
> -- 8< --
> 
> It seems that if pairing fails, the kernel disconnects from the device
> and the DBus method returns AuthenticationFailed, but I can't see any
> way to figure out whether or not a device supports pairing without
> trying to pair with it.
> 
> Am I missing some method for determining whether or not a device
> supports pairing?  Or do we need to handle SMP_PAIRING_NOTSUPP
> specially?
> 
> I'm happy to work up some patches if the latter, but I'd like to make
> sure I'm heading in a sensible direction before starting on that!

I do not remember any indication from the Bluetooth Core specification that would tell you in advance if you support pairing or not. Mainly since most devices actually just support pairing. Can you show us the btmon trace output of the advertising reports.

One thing that I can think of is that Pair Device should return a reasonable error code so that bluetoothd can detect non-supported pairing and treat it as non-bonded device. Best would be a full btmon -w trace.log trace with a recent kernel that also monitors mgmt commands and events.

Regards

Marcel

Re: Determining whether a Bluetooth device supports pairing

[John Keeping]

[-- Attachment #1: Type: text/plain, Size: 3607 bytes --]

Hi Marcel,

On Thu, 18 May 2017 16:56:14 +0200, Marcel Holtmann wrote:

> > Am I missing some method for determining whether or not a device
> > supports pairing?  Or do we need to handle SMP_PAIRING_NOTSUPP
> > specially?
> 
> I do not remember any indication from the Bluetooth Core specification
> that would tell you in advance if you support pairing or not. Mainly
> since most devices actually just support pairing. Can you show us the
> btmon trace output of the advertising reports.

Here's the advertising report and scan response:

-- >8 --
> HCI Event: LE Meta Event (0x3e) plen 33
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable undirected - ADV_IND (0x00)
        Address type: Public (0x00)
        Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
        Data length: 21
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        128-bit Service UUIDs (complete): 1 entry
          Vendor specific (03b80e5a-ede8-4b33-a751-6ce34ec4c700)
        RSSI: -66 dBm (0xbe)
> HCI Event: LE Meta Event (0x3e) plen 42
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Scan response - SCAN_RSP (0x04)
        Address type: Public (0x00)
        Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
        Data length: 30
        Name (complete): Akai LPK25 Wireless
        Slave Conn. Interval: 0x000a - 0x0014
        TX power: 0 dBm
        RSSI: -67 dBm (0xbd)
-- 8< --

> One thing that I can think of is that Pair Device should return a
> reasonable error code so that bluetoothd can detect non-supported
> pairing and treat it as non-bonded device. Best would be a full btmon
> -w trace.log trace with a recent kernel that also monitors mgmt
> commands and events.

I've attached the full trace, but I think this is the interesting
section:

-- >8 --
@ MGMT Command: Pair Device (0x0019) plen 8
        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
        Capability: KeyboardDisplay (0x04)
< ACL Data TX: Handle 3585 flags 0x00 dlen 11
      SMP: Pairing Request (0x01) len 6
        IO capability: KeyboardDisplay (0x04)
        OOB data: Authentication data not present (0x00)
        Authentication requirement: Bonding, MITM, SC, No Keypresses, CT2 (0x2d)
        Max encryption key size: 16
        Initiator key distribution: EncKey Sign LinkKey (0x0d)
        Responder key distribution: EncKey IdKey Sign LinkKey (0x0f)
> HCI Event: Number of Completed Packets (0x13) plen 5
        Num handles: 1
        Handle: 3585
        Count: 1
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
      SMP: Pairing Failed (0x05) len 1
        Reason: Pairing not supported (0x05)
@ MGMT Event: Authentication Failed (0x0011) plen 8
        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
        Status: Authentication Failed (0x05)
@ MGMT Event: Command Complete (0x0001) plen 10
      Pair Device (0x0019) plen 7
        Status: Authentication Failed (0x05)
        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
< HCI Command: Disconnect (0x01|0x0006) plen 3
        Handle: 3585
        Reason: Authentication Failure (0x05)
> HCI Event: Command Status (0x0f) plen 4
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4
        Status: Success (0x00)
        Handle: 3585
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8
        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
        Reason: Connection terminated by local host (0x02)
-- 8< --


Regards,
John

[-- Attachment #2: lpk25.log --]
[-- Type: application/octet-stream, Size: 4333 bytes --]

Re: Determining whether a Bluetooth device supports pairing

[Marcel Holtmann]

Hi John,

>>> Am I missing some method for determining whether or not a device
>>> supports pairing?  Or do we need to handle SMP_PAIRING_NOTSUPP
>>> specially?
>> 
>> I do not remember any indication from the Bluetooth Core specification
>> that would tell you in advance if you support pairing or not. Mainly
>> since most devices actually just support pairing. Can you show us the
>> btmon trace output of the advertising reports.
> 
> Here's the advertising report and scan response:
> 
> -- >8 --
>> HCI Event: LE Meta Event (0x3e) plen 33
>      LE Advertising Report (0x02)
>        Num reports: 1
>        Event type: Connectable undirected - ADV_IND (0x00)
>        Address type: Public (0x00)
>        Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
>        Data length: 21
>        Flags: 0x06
>          LE General Discoverable Mode
>          BR/EDR Not Supported
>        128-bit Service UUIDs (complete): 1 entry
>          Vendor specific (03b80e5a-ede8-4b33-a751-6ce34ec4c700)
>        RSSI: -66 dBm (0xbe)
>> HCI Event: LE Meta Event (0x3e) plen 42
>      LE Advertising Report (0x02)
>        Num reports: 1
>        Event type: Scan response - SCAN_RSP (0x04)
>        Address type: Public (0x00)
>        Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
>        Data length: 30
>        Name (complete): Akai LPK25 Wireless
>        Slave Conn. Interval: 0x000a - 0x0014
>        TX power: 0 dBm
>        RSSI: -67 dBm (0xbd)
> -- 8< --

so there is nothing that tells us that pairing is not support. Except the UI could use the Vendor specific UUID to decide to do special handling of this device.

>> One thing that I can think of is that Pair Device should return a
>> reasonable error code so that bluetoothd can detect non-supported
>> pairing and treat it as non-bonded device. Best would be a full btmon
>> -w trace.log trace with a recent kernel that also monitors mgmt
>> commands and events.
> 
> I've attached the full trace, but I think this is the interesting
> section:
> 
> -- >8 --
> @ MGMT Command: Pair Device (0x0019) plen 8
>        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
>        Capability: KeyboardDisplay (0x04)
> < ACL Data TX: Handle 3585 flags 0x00 dlen 11
>      SMP: Pairing Request (0x01) len 6
>        IO capability: KeyboardDisplay (0x04)
>        OOB data: Authentication data not present (0x00)
>        Authentication requirement: Bonding, MITM, SC, No Keypresses, CT2 (0x2d)
>        Max encryption key size: 16
>        Initiator key distribution: EncKey Sign LinkKey (0x0d)
>        Responder key distribution: EncKey IdKey Sign LinkKey (0x0f)
>> HCI Event: Number of Completed Packets (0x13) plen 5
>        Num handles: 1
>        Handle: 3585
>        Count: 1
>> ACL Data RX: Handle 3585 flags 0x02 dlen 6
>      SMP: Pairing Failed (0x05) len 1
>        Reason: Pairing not supported (0x05)
> @ MGMT Event: Authentication Failed (0x0011) plen 8
>        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)
>        Status: Authentication Failed (0x05)
> @ MGMT Event: Command Complete (0x0001) plen 10
>      Pair Device (0x0019) plen 7
>        Status: Authentication Failed (0x05)
>        LE Address: A0:E6:F8:4A:AE:AD (Texas Instruments)

So I think we should return a proper error code that indicates that Pairing is not supported here. That way then bluetoothd can decide to handle this gracefully. Frankly I have not seen a device that doesn't support pairing in a long time. Also we should add proper mgmt-tester test cases for pairing not supported cases.

Regards

Marcel