iPhone7 + nrf52 + SDK12/s132 doesn't connect

[Ray]

I have an odd situation. I've been using an iPhone 5 and 6 to connect to, and test against, both an nRF51 (redbear nano) and the same code built for nRF52. It works fine.

Today I provisioned an iPhone 7, with the latest version of ios of course.

And my app works perfectly fine with the nRF51, but it is completely unable to talk with the nRF52.

When I explore using nRF Connect on the iPhone 7, as you'd expect I can see everything perfectly when looking at the nRF51.

But when I explore the nRF52 using nRF Connect, and tap the advertised device, something different happens. On the Service screen, it says "Connected", however there are zero advertised services listed. It is truly bizarre.

Using wireshark I've done a capture - see response.

I am not an expert at on-wire analysis or even wireshark, so I'm hoping that you might be able to suggest what I do to take next steps to debug.

Your thoughts would be appreciated; thanks.

[Ray]

I know that this hasn't gotten attention yet, but I really hope someone from Nordic would please comment because it's really a blocker.

I have now reduced this to being an SDK V12 issue. Meaning, the following all work perfectly with my app and Nordic's own: iPhone 5s + nRF51822 + SDKV11/S130 iPhone 7 + nRF51822 + SDKV11/S130 iPhone 5s + nRF52822 + SDKV12/S132

It fails, with my app and Nordic's own, on: iPhone 7 + nRF52822 + SDKV12/S132

FYI, because I know that this is likely to be the very first thing that a Nordic employee would reasonably ask, I've now eliminated my app from the equation.

These two captures are from the SDKV12 ble_peripheral hrs app, using the up-to-date nRF Toolbox app on the iPhone.

I'm running the hrs app on my nRF52832.

This capture is done using the iPhone 5s running iOS 9.3.5, and it works perfectly:

dl.dropboxusercontent.com/.../hrs-nrf52-iphone5s-good.pcapng

This capture is done using the iPhone 7 running iOS 10.0.1, and it fails the same way as my app failed above:

dl.dropboxusercontent.com/.../hrs-nrf52-iphone7-bad.pcapng

[RK]

Doubt it's an SDKV12 SDK issue, more likely an S132 V3 issue. The captures don't show anything particularly interesting, it does show the exchange of max TX/RX length information (LL data length) in the bad capture because the softdevice identifies as BTLE 4.2.

It would be interesting to see a dump of iPhone7 -> S132V2 (SDK11 if you like) or to nrf51822 running S130, that should show a similar start. The dump you have the phone is BTLE 4.1

I don't understand the random L2CAP message from the master in the middle of the whole thing, in either dump, it's marked as a continuation but doesn't continue anything.

I'd be inclined to say iOS bug at this point. I don't know if any phone previous to iPhone 7 identifies as BTLE 4.2, and there can't be many products out there running S132V3. The nRF52 has replied to everything, the phone isn't asking more questions, which it should be.

[Ray]

Well indeed it works with the sdk11 soft device. And way above you will see a capture of the iPhone 7 talking to an nrf51.

Bottom line is that indeed it is likely softdevixe behavior that needs to be fixed to do whatever it was that it used to do in the sdkv11 softdevice.

[RK]

No I still think it's iOS BLE4.2 support which is most-likely at fault here. The nRF52 has replied to every message sent by the phone, properly, fully and completely and continues to respond to empty PDUs which the phone continues to send. The connection isn't timing out, so the phone isn't expecting a reply from the nRF52 which it's not getting. iOS hasn't sent an MTU request, not that it really needs to, but it's unusual, however the next request, either MTU or feature or discovery needs to come from iOS, there's nothing the softdevice has to send at this point.

And in the previous iPhone7/SD130 capture you can see that the softdevice responds to the data length request with unknown, that's the point of difference. In the S132V3 version, nRF responds with 0x1b as the tx and rx lengths, correctly. It's after that that iOS stops doing anything.

[RK]

couple of things you could try - actually set a long data packet length, set it to 251 bytes, which is what the phone is claiming to support, see if that jerks it out of inactivity.

One thing to note - wireshark (still) decodes feature bits backwards, so the softdevice is actually reporting LE Security + LE Data Packet Extension, not what wireshark dissects, I've reported this, should have done it years ago, it's been like that since version 1.08 or something.

Also since the softdevice does support LE Ping I don't know why that flag isn't set - Nordic?

And finally it's rather odd that the phone starts the Data Length Extension procedure before it checks the features flag, but it doesn't really matter, odd though.

On the iOS side are you getting the bluetooth Connect callback and starting characteristic discovery, or is the phone not even reporting itself connected?