problem of re-requesting frequent pairing for no apparent reason

[trdop]

Hello the Nordic Team,

First, I wish you all a Happy New Year 2018, with a lot of good health and success in your professional and personal projects. Secondly, I come here to make aware of a problem that is happening to us, with our device and an untimely pairing request with and not predictable.

As a reminder:

A few months ago, we started to go on the SDK12.2, our device is functional as such and we use roughly the following stack: • ANCS • UART/NUS • DFU Button Less • Libs for MEMS

I am paralleling making the switch to the latest version 14.2, hoping that it neutralize the problem, if it could come possibly from a bug in the SoftDevice (?).

In any case for example, I do once pairing on a device for example debug of the month and for example, (I do not have too much log back and concrete use cases) but after two or three weeks, I start to re-have a request for pairing on iOS, I say iOS because on Android there is no Pairing, Pairing serves us only for the ANCS.

If you have some ideas to investigate, I'm interested. Or if it just happens to you too thank you to report it.

Thanks a lot guys, And have a nice day

733B503351854BF28BC0279497EC5600.png

[Petter Myhre]

I don't think this is a common issue, but I'm not sure.

Very difficult to say what could cause this, and hard to test for you of course. A sniffer trace would be very helpful, but you can't really do one for 3 weeks. It would be interesting to know more about what is happening before you get the pairing request. Do you have any print out or logs that could shed some light on that?

[trdop]

Of course very difficult to say what could cause this even for me ! But I think it's interesting, during the last days I was able to investigate a little more. So I realized that looking at the logs of my App iOS and the Core Log of the System > Bluetooth, there are two types of errors on the Bluetooth when I connect or make echange to my device:

— "[CoreBluetooth] XPC connection interrupted" <<<< seems to be invisible to the overall behavior of the app and device

— "[CoreBluetooth] XPC connection interrupted, resetting" <<<< cause a REBOOT of my phone's Bluetooth server with the resulting consequences: ie if a car radio speaker is connected or wireless headphones and the person is in communication! oops losses of the device communcation ... etc

• and it is at this precise moment, that I have this log message, that occurs that I have at the same time > the alert of re-pairing on my phone to my device ... so there is a link of cause to effect !

Now what, I can understand is that : I manage to reproduce this problem almost systematically by being on my device in version 8 (sdk12.2) while being paired, then I made an update to my version v10 of my hardware app in OTA (and in the making of this update, I create new characteristic - so I make a BT OFF / ON to flushe the iOS GATT cache ...) and that's when when after I switch OFF / ON my IOT device that appears these pairing messages ...

My questions are now these:

— There is a link with this literature: devzone.nordicsemi.com/.../ (do I have, to do the same thing in my code?)

— would it be possible that there is a link with this story of CBUUID, forums.developer.apple.com/.../39094 (One quote mentions nRF51 / 52)

Eldorado Nov 24, 2016 12:12 AM (in response to mikekasp) Hey Mike,

can you tell me which Bluetooth chip you are using? Is it a Nordic nRF51 or another Nordic chip?

———————————————————————————————————————————————————— ————————————————————————————————————————————————————

[UPDATE] : as requested by Petter Myhre, the .pcapng file captured with Wireshark (v2.4.4) and NRF51Dongle with nrf_sniffer_2.0.0-beta

• It's really bad luck, I do not know why, I can not reproduce what happened yesterday… (multiple ask of pairing)

• I still put you here in attachement, a packet capture of a normal pairing sequence, maybe you could tell me if you already see things that are not normal here

— PACKET # 1 > 155 : advertising

— PACKET # 155 > 1245 : bounded (the device switched from ON to OFF at 2 times during that)

dop_5cc4__ADV_+PAIRING+_2x_OFF_ON.pcapng

[Petter Myhre]

Could you edit your question and add this as an update instead? If you are able to reproduce it easily, could you try to do a sniffer trace of the complete communication (from first pairing to re-pairing)? And add that as well?

[Petter Myhre]

Looks normal. First bonding is done, then after disconnection and connect the link is re-encrypted without bonding again.