Use of GATT security (peer_manager) when using the MESH_PROXY feature of a mesh/ble coexistence.

[ccasebeer]

Our original BLE stack application on the nrf52840 has integrated encryption. It uses LESC with MITM and bonding.

I have gotten a certain level of run time success with BLE and MESH coexistance on our platform.

nrf5_SDK_17.0.2

nrf5_SDK_for_Mesh_v5.0.0

I can successfully provosion the device and retrieve mesh model values from the provisioned device.

If I enabled MESH_FEATURE_GATT_PROXY_ENABLED in the mesh SDK, I can see GATT before and after provisioning (however after provisioning gets dicey, with the GATT coming in and out of being seen by nrf connect IOS)

We are working on adding mesh alongside our standard BLE GATT program.

My questions are:

If I want to access all the BLE GATT characteristics that I had setup originally in strict BLE with BLE/MESH coexistance, do I need the

MESH_FEATURE_GATT_PROXY_ENABLED as defined in nef_mesh_config_app.h

It certainly feels like it. If I successfully mesh provision the device and I don't have MESH_FEATURE_GATT_PROXY_ENABLED, the device seems
to no longer advertise all the standard GATT characteristics we've setup.

If I want GATT after mesh provisioning, do I need MESH_FEATURE_GATT_PROXY_ENABLED?

Second question:

If I have turned bonding/pairing/encryption on multiple GATT characteristics in standard BLE, can I still use this encryption in mesh coexistence with mesh proxy enabled?
Do I need it?

It appears that pairing/bonding might not be supported with mesh proxy as indicated by this area of source code in mesh_gatt.c

        case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
            NRF_MESH_ERROR_CHECK(sd_ble_gap_sec_params_reply(p_ble_evt->evt.gap_evt.conn_handle,
                                                             BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP,
                                                             NULL,
                                                             NULL));

So far, I can access unencrypted characteristics before and after provisioning the mesh stack, but error out if access any of the characteristics with enhanced security are accessed at any time.

This is the previous definition of security on the characteristics in question:

////This is the init state of peer_manger.
#define SEC_PARAM_BOND                  1                                           /**< Perform bonding. */
#define SEC_PARAM_MITM                  1                                           /**< Man In The Middle protection required (applicable when display module is detected). */
#define SEC_PARAM_LESC                  1                                           /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS              0                                           /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_DISPLAY_ONLY                /**< Display I/O capabilities. */
#define SEC_PARAM_OOB                   0                                           /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE          7                                           /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE          16                                          /**< Maximum encryption key size. */
  
  
////This is the init state of peer_manger.
// Security parameters to be used for all security procedures.
sec_param.bond           = SEC_PARAM_BOND;
sec_param.mitm           = SEC_PARAM_MITM;
sec_param.lesc           = SEC_PARAM_LESC;
sec_param.keypress       = SEC_PARAM_KEYPRESS;
sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;
sec_param.oob            = SEC_PARAM_OOB;
sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
sec_param.kdist_own.enc  = 1;
sec_param.kdist_own.id   = 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id  = 1;


//The characteristics attribute read and write permissions are set with
BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM()

I referenced the example of PB-GATT turn on in the example provided here:

https://devzone.nordicsemi.com/f/nordic-q-a/53837/including-nrf5-sdk-for-mesh-functionality-in-an-nrf5-sdk-example/235538#235538

We also need PB-GATT as we want to provision via phone.

[ccasebeer]

Thanks Simon.

We plan to use vanilla BLE to connect to regular services (a huge one being Nordic NUS) directly from a user's phone.

The plan would be to also merge in PB-GATT provisioning inside that same user phone app, using nordic mesh android/ios sdk.

There is really no overlap between mesh and BLE.

I'm going to get back to you, I am examing the differences between a couple init functions defined in ble_softdevice_suppor.c and seeing if they are any different from what I already have. Today, I don't think I need those after all. They appear to be largely the same! except for a define to

    NRF_SDH_SOC_OBSERVER(mesh_observer, NRF_SDH_BLE_STACK_OBSERVER_PRIO, on_sd_evt, NULL);

I'm pretty sure we don't need mesh proxy. No need to relay GATT in the Mesh, just need to access it individually per device.

[ccasebeer]

I'll try at least get some specifics of where I am at currently.

I have tried using these functions as we've previously defined them for our stock BLE stack as well as the ones defined in ble_softdevice_support.c of the mesh sdk /examples/common.

The closest example I've found to trying to get PB-GATT online with coexistance appears to use the functions as defined in the ble_softdevice_support.c.

ble_stack_init
gap_params_init
conn_params_init

In both instances, I'm currently running into a an NRF error I'm having trouble debugging. I either use the ones a s previously defined in ble stock or the ones in ble_softdevice, where the calls in mesh_main, refer to main or vice versa, where the calls in main refer to the calls in ble_softdevice_support.c

<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at ../../../examples/common/src/mesh_adv.c:147

Which is this function.

    uint32_t err_code = sd_ble_gap_adv_data_set(m_gap_adv_data.adv_data.p_data,
                                                m_gap_adv_data.adv_data.len,
                                                m_gap_adv_data.scan_rsp_data.p_data,
                                                m_gap_adv_data.scan_rsp_data.len);

Any ideas? I have this weird feeling that BLE is trying to advertise twice?

I have tried to increase NRF_SDH_BLE_VS_UUID_COUNT twice, with accompanying changes to the linker files, as described by debug out messages suggesting new changes to ram start and ram size. 

Thanks,
Chris.

[Simonr]

Hi

What SoftDevice API version are you using? Are you positive that the #if loop is skipped and goes to sd_ble_gap_adv_data_set()? Seeing as you're using the latest SDK versions I would think that the SoftDevice API version will default to the newest, and use sd_ble_gap_adv_set_configure() instead of sd_ble_gap_adv_data_set(). Either way, the NO_MEM error is generally called for the same reason in all functions, being that there is not enough memory to configure a new advertising handle, so you might want to try updating an existing advertising handle instead.

Best regards,

Simon

[ccasebeer]

Thanks for the reply Simon.

Indeed, I am going to sd_ble_gap_adv_set_configure() instead of sd_ble_gap_adv_data_set(). I double checked my soft device which is s140 @ 7.2.0. Forgive me, working in VSCODE without full makefile/define awareness yet.

I double checked I'm including the correct header files, targeting the s140, as this is a call into the softdevice.

I suppose now, given my path is how do I either update the existing handle or give the soft device enough memory to create a new operating handle. Is the latter an option?

Can two handles exist at the same time? I see where my main application uses the handle and sets up it's own calls to sd_ble_gap_adv_set_configure() through the ble_advertising.c file. The same thing is going on in the mesh_adv.c and it's calls to sd_ble_gap_adv_set_configure().

What would you recommend? What would be easier. Can I just increase memory? Is there an sdk config setting I need to add to get the advertising handle limit increased? Usually I can elicit a debug message about memory needing to be increased and increasing it accordingly in the linker settings.

[ccasebeer]

Using ble_advertising_advdata_update()

I was able to move to the use the same advertising handle between mesh and main. It appears having two advertising handles is not allowed for the soft device, causing the NRF_NO_MEM.

However, the provisioning will now halt on Requesting Composition Data in the Mesh IOS/Android applications.

This also happens when I turn OFF the Proxy feature of the stock PCA10056 sensor/server base demo in the MESH SDK.

So now I'm back to thinking I need the mesh proxy feature for our application.

Do I need mesh proxy?