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.

[Simonr]

I'm not sure why you would lose access to your GATT services over regular BLE if proxy is disabled. How exactly have you set up your GATT services in this node? Are they related to the mesh network at all, because they shouldn't it seems to me. Also, what kind of connection are you using (and planning to use) between this node and the phone?

Best regards,

Simon

[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.