[Zephyr-devel] mesh: relay traffic when relay state is 0x02 (not supported)


Vikrant More <vikrant8051@...>
 

I applied your recent patch (that is https://github.com/zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App) if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".


Please re-check & confirm this.
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



On Sun, Dec 3, 2017 at 7:42 PM, Vikrant More <vikrant8051@...> wrote:
Sir I'm talking about this(attached image) ON/OFF setting which available during configuration of Device.

As per my observation, whatever we set here doesn't get reflected at device side. Means if we turn off relay, NODE still relaying the received packets.

>>The GATT service should be gone. After provisioning, if you disconnect,
>>reconnect, and are still able to discover the provisioning service UUID
>>in the GATT database, then that's a bug.


After provisioning, Silicon Labs Mesh App is not able to discover the NODEs. But it get detected in nRFConnect App (App provided by Nordic Semiconductor) as unknown device (not as Zephyr). We can easily connect with it & easily access Mesh Provising Service using the same App.

When I send some random data via it, on terminal of NODE we get error as "message is too short". Means NODE accepts data from any device. 

If possible please try all my observations using SiliconLabs App & nrf52840_pca10056 board.

Correct me if I'm wrong somewhere.

Thank You !!

On Dec 3, 2017 2:00 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Sun, Dec 03, 2017, Vikrant More wrote:
> If I configured Relay OFF/ Proxy Off using Silicon Labs Bluetooth Mesh App
> that does not change anything in reality.  If Relay is ON as per firmware
> then it remains ON.

What do you mean by this? That the state value remains 0x01 or that the
node keeps relaying regardless of the value? If you have GATT Proxy
enabled then you're observing the same thing as Steve reported, and this
should get fixed by my latest pull request.

> Plus even after provisioning, I can connect to #MeshProvisioningService on
> NODE using #nRFconnect App and also able to send data to it.

The GATT service should be gone. After provisioning, if you disconnect,
reconnect, and are still able to discover the provisioning service UUID
in the GATT database, then that's a bug.

Johan



Johan Hedberg
 

Hi Vikrant,

Please try to avoid top-posting, especially if the existing thread is
using inline quoting.

On Tue, Dec 05, 2017, Vikrant More wrote:
I applied your recent patch (that is https://github.com/
zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App)
if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.
Are you talking about adv-adv relaying or GATT-adv relaying (or
vice-versa)? Steve seemed to confirm that the current code works as it
should.

Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs
Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte
of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".
Are you sure nRF connect isn't juts holding on to cached GATT database
information. When provisioning is complete Zephyr will remove the
provisioning service and replace it with the GATT proxy service. This
means that the GATT Proxy service will likely get the same attribute
handle values as the provisioning service. The Zephyr GATT server will
send out appropriate service changed indications for this, but if the
client doesn't support this it might get confused (thinking the old
service is there even though it has actually been replaced with another
one). You'd probably need to find a way to force re-discovery of
services (possibly by disconnecting & reconnecting).

Johan


Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Johan Hedberg wrote:
Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs
Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte
of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".
Are you sure nRF connect isn't juts holding on to cached GATT database
information. When provisioning is complete Zephyr will remove the
provisioning service and replace it with the GATT proxy service. This
means that the GATT Proxy service will likely get the same attribute
handle values as the provisioning service. The Zephyr GATT server will
send out appropriate service changed indications for this, but if the
client doesn't support this it might get confused (thinking the old
service is there even though it has actually been replaced with another
one). You'd probably need to find a way to force re-discovery of
services (possibly by disconnecting & reconnecting).
For the record, I just did a quick test with the LigthBlue app (similar
to nRFConnect) and it correctly shows that the Provisioning service
(UUID 0x1827) gets replaced by the GATT Proxy service (UUID 0x1828)
after provisioning.

Johan


Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Johan Hedberg wrote:
On Tue, Dec 05, 2017, Vikrant More wrote:
I applied your recent patch (that is https://github.com/
zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App)
if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.
Are you talking about adv-adv relaying or GATT-adv relaying (or
vice-versa)? Steve seemed to confirm that the current code works as it
should.
I took a second look at the logic in bt_mesh_net_relay() and indeed it
was still buggy. Thanks for catching this. The following pull request
(which I'm still doing a bit of testing on) should fix the issue:

https://github.com/zephyrproject-rtos/zephyr/pull/5275

Johan