BLE stack 1.4.1 Connection problem between Bluetooth Smart keyboard and iPhone (iOS 8.2)

Hello Sarah,

Setting the DEFAULT_PAIRING_MODE to GAPBOND_PAIRING_MODE_WAIT_FOR_REQ seems to ensure the best HOGP / HID compatibility with iOS 8.2+. This change was tested on v1.4.1 with TI KeyFob HW.

Can you provide more details on what sort of connection problem you are experiencing? Is it 100% reproduced or partial? Does it happen on initial pairing or subsequent re-connect?

Best wishes

Hello JXS,

The problem: 100% of the time with iOS 8.2+, the first time I pair, if I go to an editor, I am unable to type. If I reboot the BLE or turn the iOS device bluetooth off and on, I can type. Subsequent re-connect works fine.

I have tested with 1.4.0 TI KeyFob HW with DEFAULT_PAIRING_MODE = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ. This shows the problem.

I have tested with 1.4.1 TI KeyFob HW with DEFAULT_PAIRING_MODE = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ. This does not show the problem.

I migrated my new project code to the new 1.4.1 code stack and set DEFAULT_PAIRING_MODE = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ. This does show the problem.

This makes me believe I have migrated the code incorrectly. 

I want a list of functions, files, and macros that need to be updated to get rid of the problem. I will then check everything on that list to make sure it is up-to-date. 

Some functions could not be updated fully because we made changes to them necessary for our project's functionality. I need to know which ones could be a problem.

Thanks,

S

Hello Sarah,

If you take sniffer trace with the TI keyfob (correctly working) and compare to your v1.4.1 ported project, do you see any differences in BLE behavior? Is some other part of your code initiating pairing? Comparing the working vs non-working sniffer traces is probably the best first step in debugging.

Best wishes

Hello JXS,

The hardware that my new project is on, is not reliable with the TI packet sniffer.

Moreover, even if I saw differences, I would not know what to do about it. Also, some differences are a necessary part of the project and I need to be able to distinguish which differences are important..

This is why, to start with, I want to make sure I have updated all relevant files and parameters.

I suspect that a function with project changes has been incorrectly updated. Once I make a list of which functions are suspect, I will have a better idea of what to look for.

Which files outside of GapBondManager are involved in establishing the initial pairing? What did the change to fix this iOS 8.2+ problem entail?

-S

Hello Sarah,

Using a sniffer will help identify the issue and solution. I would recommend using an Ellisys or Frontline sniffer, these will give better HID protocol analysis than the TI sniffer. Without this, you're flying blind.

It's not clear why changing to GAPBOND_PAIRING_MODE_WAIT_FOR_REQ fixes the issue on iOS 8.2+, although it appears (from analysis of sniffer traces) that maybe the iOS device has issues with the relative timing of the Slave Sec Req vs the INSUFFICIENT_AUTHENTICATION sent in response to the first HID characteristic being read. Again, there were no BLE protocol issues in any of the sniffer traces, so it's only a guess since the behavior is internal to the iOS stack.

For porting you can refer to the porting guide on the wiki as well as diff the profile code from 1.4.0 to 1.4.1.

Best wishes

Hello JXS,

Can you clarify?

By INSUFFICIENT_AUTHENTICATION, do you mean the GAP_PAIRING_REQ_EVENT triggers an INSUFFICIENT_AUTHENTICATION response for devices when the BLE is not on their whitelist?

Then presumably once we get that message, we would send a slave security request?

If we have a device that is a peripheral and has GAPBOND_PAIRING_MODE_WAIT_FOR_REQ, when/where is the slave security request done?

Every instance of GAP_SendSlaveSecurityRequest or gapBondMgrSlaveSecurityReq that I have found, is conditional such that it must be either a central device, or have gapBond_PairingMode = GAPBOND_PAIRING_MODE_INITIATE.

Thanks,
-S

Hi Sarah,

Do you change connection parameters?(connection interval/slave latency/timeout)

Hello Sara,

INSUFFICIENT_AUTHENTICATION is sent in response to a Client read or write of any Characteristic which has a permission requiring an authenticated link. See "3.2.5 Attribute Permissions" in the BT4.1 Core Spec, Volume 3, Part F. The Client will then send a Pairing Request in response to this message.

Note that all HOGP HID characteristics require an authenticated link. Since you are using iOS for the HID host, you should not be enabling Whitelists.

Best wishes

Hello kimi_hu

Yes, I made them identical to the project that worked (keyfob and HIDEmuKbrd with stack 1.4.1). The problem still shows up.

Are there any other parameters that are important to this process, that I should check?

Thanks,

S

Hello JXS,

I successfully captured two sniffer traces of the link being established, one with the known working case and one with the failure case.

If I assume the critical area is between the Insufficient Encryption message and the SM pairing request, like you said, then one thing does stand out as a difference between the cases.

In the bad case the order of events is:

LL channel map request

Insufficient encryption response

SM pairing request

In the good case the order of events is:

Insufficient encryption response

LL channel map request

SM pairing request

What controls when the LL channel map request occurs? What would make it different in the two cases? 

Also, here are the packet snif captures. The LL request is number 137 in the bad case, 156 in the good case.

badcase.psdgoodcase.psd

Thanks in advance,

-S

Hi Sarah,

Looking at the sniffer, it does show that the "bad" case does not send the Salve Security Req, but the sniffer is not able to decode the encrypted phase of the log. The LL channel map is sent by the Central in response to varying channel conditions (i.e., Wi-Fi interference), it's up to the Central as to if/when it's sent. It's probably likely that if you take several traces, you'll see varying times when the LL channel map is sent by the iOS device.

One thing that I did notice is you are not using the TI default BLE MAC address (BD_ADDR). Do you see the same behavior with the default MAC address?

Best wishes

Hello JXS,

We are not directly changing the BD_ADDR anywhere in the project.

Are there any indirect ways of changing the BD_ADDR that don't use the term BD_ADDR?

I don't believe we are intentionally changing the BD_ADDR.

Or are you referring to:
1. We changed the name displayed in scanData[]
2. We use the secondary IEEE address (customized) instead of the primary

Please clarify,
-S