• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 1644 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564B product with Bluetopia stack failing to pair with iOS device, status GAP_LE_PAIRING_STATUS_UNSPECIFIED_REASON (0x0B)

Brett Wingeier
Prodigy 85 points

Hi all -

I'm developing a BLE product using the CC2564B, MSP430, and Bluetopia stack v1.5R2.  Everything seems to be working just fine, and I can connect / pair / start up encryption / exchange IRK / resolve random addresses successfully with my Cypress CySmart development tool (dongle and software on PC that act as BLE master).  It also works correctly on Android 5.0 (Bluetooth LE Scanner utility app).

However, when I try to pair from an iOS device, pairing ends before the IRK is exchanged.  This is consistent whether I use our app under development, or BLE Utility from the app store.  In the Bluetopia GAP LE callback, this manifests as a 0x0B status code in the latPairingStatus event (which, incidentally, doesn't seem to correspond directly with an HCI event??).  I'm not quite sure what triggers the 0x0B and in the stack it's defined as GAP_LE_PAIRING_STATUS_UNSPECIFIED_REASON, which does not help me understand more.

Below is the log from the unsuccessful pairing.  I've added a dump of data transmitted (T: tag) and received (R: tag) over the HCI interface.  Most of it I can parse out, although I'm unsure of the role of the ACL data going back and forth near where the pairing status error is logged.

Hoping someone here can help.  Let me know if any more information is needed.  I'll post if I find an answer meanwhile.  Thanks so much!

- B

// Initial connection is complete at this point - MTU 23, LE, with remote (random bdaddr) 0x465C2CF7F077.

...
T: 0201040A000600040005011A000328
R: 0201240700030004000A1B00
R: 0413050101040200
T: 0201040C00080004000B00000000000000
R: 0201240700030004000A1E00

>> Rejected read due to insufficient authentication.

T: 020104090005000400010A1E0005
R: 0201240B000700060001040005100303
R: 0413050101040200

>> Pairing Request: 0x465C2CF7F077.
IO Capability: lcKeyboardDisplay.
MITM: TRUE.
Bonding Type: Bonding.
OOB: OOB Not Present.
Encryption Key Size: 16.
Sending Keys:
LTK: YES.
IRK: YES.
CSRK: NO.
Receiving Keys:
LTK: YES.
IRK: YES.
CSRK: NO.

>> Sending Pairing Response to 0x465C2CF7F077.

T: 0201040B000700060002030005100303

>> GAP_LE_Authentication_Response returned 0.

>> latConfirmationRequest.
>> Invoking Just Works.
T: 01182000
R: 040E0C01182000C588C2E3F253FDF7
T: 01182000
R: 040E0C011820002BBDD4FF73E3B816
T: 0117202000000000000000000000000000000000C489C3E7F256EDF428BFD7FF76F3BB15
R: 040E14011720008DE1C74711A7404630D9E2C906575884
T: 01172020000000000000000000000000000000005DF5613C1AF637B6C7F5BE8F06575884
R: 040E140117200086F1AE6E079D3A9DF3C39B2085AA17A1

R: 0413050101040100
R: 30
T: 31
R: 32
T: 33
R: 02
R: 012415001100060003D747D26E4FE959549FF7DDC908C10BD3
T: 0201041500110006000386F1AE6E079D3A9DF3C39B2085AA17A1
R: 020124150011000600040F28F40625DCBDE220633B86B8491590
T: 01172020000000000000000000000000000000000E29F50225D9ADE123613886BD591693
R: 040E140117200098E17CA5144C5C3B11561804662A3646
T: 011720200000000000000000000000000000000048F5DADE1F1D2BCBE67A4442662A3646
R: 040E1401172000D747D26E4FE959549FF7DDC908C10BD3
T: 02010415001100060004C588C2E3F253FDF72BBDD4FF73E3B816
T: 01172020000000000000000000000000000000000F28F40625DCBDE2C588C2E3F253FDF7
R: 040E140117200056BBD0D8CFB4A3276714FE0F0EC19B4E
R: 0413050101040200
R: 043E0D05010400000000000000000000
T: 011A2012010456BBD0D8CFB4A3276714FE0F0EC19B4E
R: 040E06011A2000010430
T: 31
R: 32
T: 33
R: 04080400010401

>> etLE_Encryption_Change with size 8.
>> Successfully encrypted in path etLE_Encryption_Change.

>>Encryption Information Request 0x465C2CF7F077.
>> Calling GAP_LE_Generate_Long_Term_Key.
T: 01182000
R: 040E0C01182000E68A51F7CC196B7A
T: 01182000
R: 040E0C011820000815D513213C8E2A
T: 011720202D23D811DE492B18298A70391C121271E68A51F7CC196B7A0000000000000000
R: 040E1401172000D7CD7B0613EEF85C4D4B86164798C445
T: 0117202028BAE13713B2204516B219D080EE4A51213C0000000000000000000000000000
R: 040E14011720008B1DDC2FE4DDCC7D8D97FD6CF1058B06
>> Encryption Information Request Response.
T: 020104150011000600068B1DDC2FE4DDCC7D8D97FD6CF1058B06
T: 0201040F000B00060007E579E68A51F7CC196B7A
>> GAP_LE_Authentication_Response (larEncryptionInformation) success.

>> Identity information requested by host.
>> Identity Information Request Response.
T: 0201041500110006000819E73CCB212B372373248423B6354516
T: 0201040C00080006000901D014A67B0B51
>> GAP_LE_Authentication_Response (larIdentityInformation) success.

R: 0413050101040200 // Packet count info
R: 0201240600020006000508 // ACL incoming, 0006 bytes
R: 0413050101040200 // Packet count info
R: 02012409000500040004 // ACL incoming, 0009 bytes

>> Pairing Status: 0x465C2CF7F077.
>> Status: 0x0B.                       // WHY, iOS?

T: 01060403010413 // Disconnect command (reason 13, remote user terminated connection)
R: 1F001F00
R: 040F0400010604 // Packet count info

T: 0201040A000600040005011F000328 // ACL outgoing, 000A bytes
R: 0413050101040100 // Packet count info
R: 04050400010416 // Disconnection complete

>> etGATT_Connection_Device_Disconnection with size 10:
Connection ID: 3.
Connection Type: LE.
Remote Device: 0x465C2CF7F077.

>> etLE_Disconnection_Complete with size 9.
Status: 0x00.
Reason: 0x16.
BD_ADR: 0x465C2CF7F077.
>> Warning - Disconnect from unknown device.

T: 0108202007020102030300FF000000000000000000000000000000000000000000000000 // Set advert data
R: 040E0401082000 // Completed set advert data
T: 010920200E0D0948616C6F20426F61726420430000000000000000000000000000000000 // Set scan response
R: 040E0401092000 // Completed set scan response
T: 0106200FA00040010001000000000000000700 // Set advert parameters
R: 040E0401062000 // Completed set advert params
T: 010A200101 // Enable advert
R: 040E04010A2000 // Completed enable advert

>> GAP_LE_Advertising_Enable success.



  • 0
    TI__Guru* 85400 points

    Hi,

    Do you have an air sniffer log that you can share?
    The ACL data before the pairing failure I believe is the SMP protocol (see below).




    I believe that the pairing is triggered by the iOS device reading an attribute (at handle 30) with encryption required flag turned on. Is it possible to initiate a pairing request first ("PairLE" from the SPPLEDemo wiki - http://processors.wiki.ti.com/index.php/CC256x_TI_Bluetooth_Stack_SPPLEDemo_App ) and see if it helps?


    Regards,
    Gigi Joseph.

  • 0 in reply to Joseph Gigi
    Prodigy 85 points
    Sniffer arrives on Monday so will test and post log then. (Thanks, TI et al, for making sniffers for less than fifty bucks!)

    Meanwhile, I did try initiating pairing from the embedded slave side after the connection was made. The only reason we're normally using the attribute read is because that is Apple's preferred pairing trigger for interacting with iOS devices. Anyway, I tried calling sendPairingRequest, which calls GAP_LE_Pair_Remote_Device() under the hood. The result was the same - pairs fine with my Cypress dongle, fails in exactly the same way with the iOS device.

    Working on this today even without the sniffer - will let you know if I figure it out, please let me know if you have any other ideas.

    thanks
    - B
  • 0 in reply to Joseph Gigi
    Prodigy 85 points
    Update: the problem seems to be that iOS doesn't like my response to the identity information request. If I configure pairing capabilities so that I never transmit an IRK, then the pairing goes through successfully. Now to figure out why this is causing problems!

    Most likely not a TI- or StoneStreet-related problem, in other words.
  • 0 in reply to Brett Wingeier
    Prodigy 85 points
    Got it. BT 4.1 core spec, vol 3, 3.6.5. I was reporting my resolvable random address in this reply and should have just been zeroing out the address type and bdaddr bytes since apparently these fields are only intended for public or static random addresses. This was making iOS cancel the pairing, which was turning up on the embedded side as a very mysterious error.

    One suggestion for StoneStreet - if the 0x0B code really does mean that the master (specifically) terminated the pairing for unknown reasons, even knowing that it was the master and not something on the embedded side would be helpful - could change the name of the error code to clarify this.

    Onward!
  • 0 in reply to Brett Wingeier
    Prodigy 85 points
    Hm. One more complication - apparently zeroing out the address type was not completely the right strategy. This worked in the short term but prevented reconnection later. I had to generate a static address and pass it back with address type of 0x01 - then the whole chain of events started working properly. Not sure how generating and passing the static address fixed anything, since I never started advertising as the static address, but apparently this strongly affected state on the iOS side.

    Incidentally, we got this working nicely days ago with the Android stack, a Linux stack, and the Cypress dongle and related Windows app. The only stumper was iOS, which apparently has some less-than-well-documented assumptions under the hood of coreBluetooth.

    I'll update further if anything else comes to light.