NFC OOB Pairing + 'conventional' pairing

[RoyCreemers]

I'm trying to combine conventional pairing with OOB NFC pairing, but I'm struggling to decide which libraries to use. I have been looking at the examples, and they all use 'nfc_ble_pair_lib.c'

Is this considered to be example code? Or a library which should preferably be used?

- This library has an assumption about when to start advertising (when an NFC device, e.g. phone is detected). In our application, we want to control advertising ourselves. E.g. Once we are advertising, we also want it to listen to the NFC peripheral. In case we are not advertising, NFC should be disabled. Is this considered to be exceptional for OOB pairing, not supported by the 'nfc_ble_pair_lib', or do I just misinterpret how to use the library?

- The library resets the I/O capabilities back to NONE (BLE_NFC_SEC_PARAM_IO_CAPS == BLE_GAP_IO_CAPS_NONE), and thereby possibly reduces security for conventional pairing. We would expect this define in the 'sdk_config', instead of locally in the source file. 

[Simonr]

Hi Roy

Yes, the NFC BLE pairing library should be used for pairing using NFC. Please read more on it on our Infocenter. If you mean if it's okay to modify it, of course it is, but if you do so, you'll have to mention that in future support cases, so that we can keep up with what's been changed.

I believe the chip, by default, will wake up and connect when an NFC device is detected. You should be able to configure this the way you want, by for example uninitializing the NFC entirely when you're not advertising.

If you take a look at the nfc_pair_lib_m.c file, you can see that BLE_GAP_IO_CAPS_DISPLAY_YESNO is used for LESC (LE Secure Connections). So if you need to, you can change the security parameters if you need to.

Due to the summer holidays in Norway, our support team is understaffed this week, and delayed replies must be expected. Sorry for the inconvenience!

Best regards,

Simon

[RoyCreemers]

Thanks for clarification. The link from the "InfoCenter" was exactly my starting point, which was also my point of confusion. It does not mention that there would be a need to modify the "'nfc_ble_pair_lib", while I would consider the existing implementation very specific for some use cases.

After your hint to look at the example with the modified "nfc_ble_pair_lib_m", this also seems to be a bit tricky. In this example, the peer manager gets configured with the I/O capabilities as defined in the sdk_config (in this example, they are in there!), but the NFC library immediately overwrites them with hardcoded settings.

However, I consider the modified version at least an improvement for our situation, since it does not infringe with the peer manager and advertisement settings. I will continue using this version for our developments (actually I would expect a version like this to be part of the SDK :))