MESH Proxy client

RE: MESH Proxy client

Hung Bui — Thu, 24 Jan 2019 16:06:49 GMT

This is new to me as well :)

Could you explain what you meant by " as mentioned what is implemented here, is from my understanding, not strictly a mesh proxy." You meant which implementation ?

I found a good material that you can have a look. Please follow the link here.

The data should be encrypted using network key , correct! It should also be encrypted with application key.

RE: MESH Proxy client

Ales — Wed, 23 Jan 2019 14:44:37 GMT

Hi,

I must admit MESH is new to me, so I'm just realizing the implications of it.

Please correct me if I'm wrong.
From my current understanding, the proxy feature should encapsulate MESH packets in an encrypted form (calls to net_packet_encrypt in the proxy code) using the assigned network encryption key. Is that correct?

This approach using a new mesh_gatt_pdu_type_t and filtering packets at this level circumvents the proxy protocol and is a totally different approach.

I will have a look at Android code for any hint, but as mentioned what is implemented here, is from my understanding, not strictly a mesh proxy.

RE: MESH Proxy client

Hung Bui — Wed, 23 Jan 2019 13:38:15 GMT

Hi Ales,

To send data from the client to the server you would need to use write command instead of using notification (sd_ble_gatts_hvx).

Could you explain the new mesh_gatt_pdu_type_t you added ? I thought it should be fine with MESH_GATT_PDU_TYPE_NETWORK_PDU ?

I would suggest to have a look into the Android/iOS app to have an idea of how this should work. You can also capture a sniffer trace when the phone connect to a proxy to see what should be sent over the air.

RE: MESH Proxy client

Ales — Wed, 23 Jan 2019 10:39:08 GMT

Hi,

thank you for the info so far.

I'm trying to implement the client proxy deriving from the server-proxy example, and what I did so far is:

(device is provisioned beforehand)

1. connect to the device

2. do a db discovery of services for the service 0x1828

3. subscribe to notifications on the TX characteristic

I'm able to get the data sent by the proxy server node in the on_hvx event handler.

NOTE the node sends the data using the mesh_gatt_packet_alloc and mesh_gatt_packet_send functions, and for sending the data a new mesh_gatt_pdu_type_t enum is defined and inserted before the MESH_GATT_PDU_TYPE_PROHIBITED value. This is the approach the node uses to send the data (I have no control over that).

I'm however not sure how to implement the sending from the client (central) to the server (node). Any suggestions on this? Is the overall procedure correct, for what I want to accomplish, or you suggest a different approach?

RE: MESH Proxy client

Hung Bui — Mon, 21 Jan 2019 15:58:57 GMT

I see, I still don't know why you want to have GATT connection to the DEVICE. I assume to unify the way you get to the cloud.

If it's what you want to do I afraid that we don't have a ready to use solution. GATT Proxy client has only be implemented on the phone.

But it should be feasible to implement that on the current mesh stack. It's just require some work. On the nRF52 we already have a mesh stack (unlike on the phone) what you need to implement is to follow what we have in the Gatt proxy server and implement a similar proxy but on reserved role. You may need to follow what described in the mesh stack to do so.

We can try to help if you find an issue, but for now we unfortunately don't have a plan to make an example for that role yet.

RE: MESH Proxy client

Ales — Mon, 21 Jan 2019 13:30:34 GMT

Yes we have full control over the gateway node.

However the topology is more like this:

RE: MESH Proxy client

Hung Bui — Mon, 21 Jan 2019 12:42:51 GMT

Hi Ales,

Please clarify do you have full control over the gateway node ?
My suggestion is to have this type of topology:

Normal Mesh Nodes <---ADV bearer---> Your Gateway node <---- BLE ----> Phone <--- Wifi/4G ---> Cloud

Is there any reason this wouldn't work ?

RE: MESH Proxy client

Ales — Mon, 21 Jan 2019 12:09:01 GMT

Hi,

I know this may sound illogical to a degree, but the fact is we have no control over the mesh nodes and this is the design we have to adapt to. Moreover, the phone(s) and our device just act as gateways for sending data to the cloud, and the customer wants to have control which device is the one connected with a node and transferring data. Provisioning is there just to take advantage of adding/removing nodes to the network and securing/encrypting the data.

RE: MESH Proxy client

Hung Bui — Fri, 18 Jan 2019 14:30:59 GMT

Hi Ales,

It's not very clear to me why you can't use normal mesh (ADV bearer) to communicate with other mesh node and use GATT proxy role (server) to communicate with the phone ? You can also have normal BLE to communicate with the phone as well. We do support doing Mesh and BLE at the same time.