Pairing with Android 6.0.1, bonding and PAN1760 unknown message 0xD1 0x5E

I have an issue the PAN1760. I am using a SPP over BLE implementation with the v2.0.4 Toshiba SDK that requires SMP_AUTH_BONDING_AND_MITM_ENABLED security. This works fine with bonding on iOS products and Android 5.1.1. With two different Android 6.0.1 devices, however, a message (0xd1 0x5e) comes from the UART that the dual mode driver is not designed to handle. I cannot find mention of it anywhere (SDK, Toshiba website, documentation). The PAN1026 does not output this message regardless of what device it connects to. Does anyone know what it means and how to respond to it appropriately? It is the only discernible difference in the paring between two Android versions and so appears related to the failure. The incoming UART (from the module) and debug is shown below.

 

ble_application_connect_callback(): 54:f8:8d:6e:f3:6c

   3 <-- 0x110x00 0x00

17 <-- 0xd1 0x5e 0x0a 0x00 0x01 0x00 0x06 0x00 0x06 0x00 0x00 0x00 0xd0 0x07

tcu_mng_le_event_handler(): unhandled MNG LE event 0xd15e received

handle_event_msg(): unknown msg received, command d15e

bt_Iterate(): handle_event_msg() failed

  3 <-- 0x0f 0x00 0x00

12 <-- 0xd5 0xc1 0x08 0x00 0x01 0x00 0x04 0x00 0x0d 0x10 0x0f 0x0f

tcu_le_smp_slv_pairing_event_handler():

Continues pairing….

  3 <-- 0x19 0x00 0x00

22 <-- 0xd5 0x48 0x12 0x00 0x01 0x00 0x02 0x15 0x55 0x58 0x6e 0x70 0x1e 0xbc 0x6d 0xeb 0xd0 0x1c 0xd8 0xd5 0xe3 0xb8

tcu_le_smp_slv_stk_generated_event_handler():

30 seconds later, no messages received ….

  3 <-- 0x0a 0x00 0x00

  7 <-- 0xd5 0x43 0x03 0x00 0x01 0x00 0xc0

tcu_le_smp_slv_pairing_failed_event_handler():

Any ideas?

4replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hello Lucas,

    I have done some initial digging, and here is what I have found thus far –

    1. Different OS treat connection creation (GAP) differently
      1. Some like iOS will use SMP all the time, hence will enforce pairing
      2. Some do or do not depend on the release and such
    2. The use of SMP and what entail with it is handled differently by different OSs…
    3. The Pairing is ALWAYS initiated by the GAP – Central, hence by the smart device’s OS

    For debug sake please do the following and let us know what you experience

     Simply remove ble_api_smp.c from the project to prevent compilation, and add ble_api_smp_slv_stub.c.

    This removes SMP handling completely and makes the pairing handler return: "pairing not supported" when ‘negotiating’ with the Central

    Gil Simsic

    Senior Application Engineer

    Panasoinc

    Reply Like
  • Hi Gil,

    Thank you for your quick response. I did as you asked and used the stub file instead of the actual one. It connects just fine (to an iOS device), but then it’s not paired with the device it connected to. They just have a temporary connection with no PIN authentication and no pairing. It fails to connect to the Android devices entirely without pairing (which is more in line with what I anticipated). What are you trying to discern with this test? The SPP over BLE profile we're using still requires the pairing to work for our security requirements.

    Lucas

    Reply Like
  • Hello Lucas, 

    Hope all is well.

    We have verified that this is indeed a bug, and a fix will be released soon.

    It will be rolled into 2.0.4.1 shortly

     

    Thank you!

    Reply Like
  • I have done some initial digging, and here is what I have found thus far –

    1. Different OS treat connection creation (GAP) differently
      1. Some like iOS will use SMP all the time, hence will enforce pairing
      2. Some do or do not depend on the release and such
    2. The use of SMP and what entail with it is handled differently by different OSs…
    3. The Pairing http://technogeekblog.com/how-to-enable-and-request-read-receipt-in-gmail/is ALWAYS initiated by the GAP – Central, hence by the smart device’s OS
    Reply Like
reply to topic
Like Follow
  • Status Answered
  • 10 mths agoLast active
  • 4Replies
  • 588Views
  • 3 Following