This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SC field in AuthReq pairing response

Hi, I noticed that I can't bond successfully with my device using iOs 9.1 with Nrf Master control panel iOs app. When I insert the PINCODE, the device immediatly disconnects, and debugging it seems that iOs sends a diconnection command (BLE_GAP_EVT_DISCONNECTED). I read that this problem is due to the fact that iOS 9 is now using the new LE Secure Connections pairing model, and the SC bit is set to 1 in the pairing request. (stackoverflow.com/.../ios-9-1-ble-connects-and-immediately-disconnects)

I checked in the bluetooth core V 4.2 specs that in bonding procedure there is that bitfield in the octect 3 of pairing response called AuthReq, but I couldn't find any way to set it with softdevice 8.0.0.0. I guess the problem could be that one, but I couldn't find a way to test it. So is it possible to change that bit or do you have any information about that problem? I know S110 8.0.0.0 is compliant to V4.1 bluetooth specs, but I have this problem and I don't know how to fix it.

Thank you

Parents
  • finally found the right piece of the spec, it's Vol 3, Part H, 2.2.3 in the 4.0 spec and Vol 3, H, 2.3.5.5 in the 4.2 spec. You use the Pairing Request (preq) in the confirm generating function one of the inputs.

    The Apple Engineer in that thread is suggesting that instead of using the paring request which was received, the softdevice is masking out the reserved bits in the AuthReq field of that request, assuming them to be zero (they were reserved previously and only now are used) and using that instead.

    That seems a bit of a stretch, I wonder what evidence he has to support suggesting that. It's certainly possible but I can't think he'd put it forward as a hypothesis so strongly unless he'd already come across that exact behavious.

Reply
  • finally found the right piece of the spec, it's Vol 3, Part H, 2.2.3 in the 4.0 spec and Vol 3, H, 2.3.5.5 in the 4.2 spec. You use the Pairing Request (preq) in the confirm generating function one of the inputs.

    The Apple Engineer in that thread is suggesting that instead of using the paring request which was received, the softdevice is masking out the reserved bits in the AuthReq field of that request, assuming them to be zero (they were reserved previously and only now are used) and using that instead.

    That seems a bit of a stretch, I wonder what evidence he has to support suggesting that. It's certainly possible but I can't think he'd put it forward as a hypothesis so strongly unless he'd already come across that exact behavious.

Children
No Data
Related