Date   

Re: Disabling Relay feature of a node of bluetooth mesh

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi Johan,

Thanks for in detailed explanation, that clarified related issues.


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Fri, Dec 8, 2017 at 2:39 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@... wrote:
> NODE1 does receives the messages and process it. But it relay/forward the
> same message to network by reducing TTL value by 1.
>
> In my case, GATT client is mobile phone so it isn't possible to know
> whether it receives something or not, for now.
>
> I'm attaching snapshot of terminal of NODE1, when it receives messages from
> NODE2 on pressing the button.

Are you concluding that the relaying happens because you see the
"Relaying packet" log message? If so, then that's a wrong assumption,
and the log message is indeed misleading. Please take a look at the
bt_mesh_net_relay() function in net.c. You'll see that the log message
is printed as soon as some basic checks are passed, but that does not
mean that bt_mesh_adv_send() at the end of the function will get called,
since that's still behind the relay_to_adv() check.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, Johan Hedberg wrote:
On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
NODE1 does receives the messages and process it. But it relay/forward the
same message to network by reducing TTL value by 1.

In my case, GATT client is mobile phone so it isn't possible to know
whether it receives something or not, for now.

I'm attaching snapshot of terminal of NODE1, when it receives messages from
NODE2 on pressing the button.
Are you concluding that the relaying happens because you see the
"Relaying packet" log message? If so, then that's a wrong assumption,
and the log message is indeed misleading. Please take a look at the
bt_mesh_net_relay() function in net.c. You'll see that the log message
is printed as soon as some basic checks are passed, but that does not
mean that bt_mesh_adv_send() at the end of the function will get called,
since that's still behind the relay_to_adv() check.
There's something not matching up with the description of your
configuration however. You said that NODE1 has both Relay and GATT Proxy
states disabled, however bt_mesh_net_relay() has the following test
before printing the log message that could be seen on your console:

if (rx->net_if == BT_MESH_NET_IF_ADV &&
bt_mesh_relay_get() != BT_MESH_RELAY_ENABLED &&
bt_mesh_gatt_proxy_get() != BT_MESH_GATT_PROXY_ENABLED) {
return;
}

So the function should bail out at this point for any packet received
over advertising when neither Relay nor GATT Proxy is set to enabled.
Your logs show that the packet was received over net_if 0, which is
BT_MESH_NET_IF_ADV, so based on the fact that the code continued from
this point it seems you had either Relay or GATT Proxy enabled.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
NODE1 does receives the messages and process it. But it relay/forward the
same message to network by reducing TTL value by 1.

In my case, GATT client is mobile phone so it isn't possible to know
whether it receives something or not, for now.

I'm attaching snapshot of terminal of NODE1, when it receives messages from
NODE2 on pressing the button.
Are you concluding that the relaying happens because you see the
"Relaying packet" log message? If so, then that's a wrong assumption,
and the log message is indeed misleading. Please take a look at the
bt_mesh_net_relay() function in net.c. You'll see that the log message
is printed as soon as some basic checks are passed, but that does not
mean that bt_mesh_adv_send() at the end of the function will get called,
since that's still behind the relay_to_adv() check.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi Johan,

NODE1 does receives the messages and process it. But it relay/forward the same message to network by reducing TTL value by 1.

In my case, GATT client is mobile phone so it isn't possible to know whether it receives something or not, for now.

I'm attaching snapshot of terminal of NODE1, when it receives messages from NODE2 on pressing the button.







--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Fri, Dec 8, 2017 at 12:23 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@... wrote:
> Here is brief about my experimental setup :
>
> 1. NODE1 : Proxy enabled, Relay disabled
> 2. NODE2 : Proxy disabled, Relay disabled
>
> Now, both nodes belong to same group, which means they are subscribed to
> same group address. When I published data on the same group address over
> GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This
> is as it was expected.
>
> NODE2 is programmed for a button interrupt, which submits a task to system
> thread with callback function as below
>
> static void pub_presence(struct k_work *work)
> {
>     static unsigned char led = 0;
>     static unsigned char trans_id = 0;
>
>     int err;
>
>     bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
>     net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
>     net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);
>
>     err = bt_mesh_model_publish(&root_models[2]);
>     if (err) {
>         printk("Error in publishing message ");
>     }
>
> }
>
> What I understand is this publishing is over advertising bearer,

Publishing is not tied to any specific bearer, rather the message is
expected to be delivered to all network interfaces the network layer is
connected to, including GATT.

> and NODE1 should not be relaying this packet. But NODE1 relays this
> packet as well.

What exactly do you mean by relaying? If NODE2 publishes the message
over advertising and NODE1 receives it over advertising, then NODE1
should at least process the message (since it's subscribed to the group
address). However upon receiving the message NODE1 should not forward
the message to any of its GATT clients or relay it back to the
advertising bearer. If you're seeing any of these last two things
happening, then I'd like to see the debug logs with ADV and NET debugs
enabled.

Also note that since NODE2 is subscribed to the same group address the
message will also be delivered locally to NODE2.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
Here is brief about my experimental setup :

1. NODE1 : Proxy enabled, Relay disabled
2. NODE2 : Proxy disabled, Relay disabled

Now, both nodes belong to same group, which means they are subscribed to
same group address. When I published data on the same group address over
GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This
is as it was expected.

NODE2 is programmed for a button interrupt, which submits a task to system
thread with callback function as below

static void pub_presence(struct k_work *work)
{
static unsigned char led = 0;
static unsigned char trans_id = 0;

int err;

bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);

err = bt_mesh_model_publish(&root_models[2]);
if (err) {
printk("Error in publishing message ");
}

}

What I understand is this publishing is over advertising bearer,
Publishing is not tied to any specific bearer, rather the message is
expected to be delivered to all network interfaces the network layer is
connected to, including GATT.

and NODE1 should not be relaying this packet. But NODE1 relays this
packet as well.
What exactly do you mean by relaying? If NODE2 publishes the message
over advertising and NODE1 receives it over advertising, then NODE1
should at least process the message (since it's subscribed to the group
address). However upon receiving the message NODE1 should not forward
the message to any of its GATT clients or relay it back to the
advertising bearer. If you're seeing any of these last two things
happening, then I'd like to see the debug logs with ADV and NET debugs
enabled.

Also note that since NODE2 is subscribed to the same group address the
message will also be delivered locally to NODE2.

Johan


Re: Stack check failure with qemu_x86

Vakul Garg <vakul.garg@...>
 

Thanks.
I could resolve this issue on qemu_x86 by increasing MAIN_STACK_SIZE in the configuration.

I am not sure whether increasing stack size is required for my hardware board as well or is it only qemu_x86 which exhausted the stack and detected stack overflow.

I am debugging some issue on ARM based board (frdm-k64f) where I suspected corruption.
Does the stack check feature works on arm as well the same way as it worked over qemu_x86?
For the hardware board, zephyr/.config shows HW_STACK_PROTECTION=n.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
Sent: Thursday, December 07, 2017 7:15 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Stack check failure with qemu_x86

Hi Vakul,

On Thu, Dec 7, 2017 at 5:38 AM, Vakul Garg <vakul.garg@nxp.com> wrote:
Hi



I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.



+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y



This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on
closure of debug connection



Can someone give me pointers how to debug the same?



***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error
addr2line -e zephyr/zephyr.elf 0x00003f6f
/home/vudentz/git/zephyr-
github/ext/lib/crypto/tinycrypt/source/hmac_prng.c:187

This is with samples/bluetooth/ipsp sample build with -DBOARD=qemu_x86





Regards



Vakul




_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
ts.zephyrproject.org%2Fmailman%2Flistinfo%2Fzephyr-
users&data=02%7C01%
7Cvakul.garg%40nxp.com%7C20e3ff6b7a5f4e6bc3dd08d53d78aa01%7C68
6ea1d3bc
2b4c6fa92cd99c5c301635%7C0%7C0%7C636482510819985701&sdata=M
ZDhH8jJ73tT
ie6npumV7caNM3jtDFJoG1WA9gZtLIY%3D&reserved=0


--
Luiz Augusto von Dentz


Re: Disabling Relay feature of a node of bluetooth mesh

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi Johan,

Here is brief about my experimental setup :

1. NODE1 : Proxy enabled, Relay disabled
2. NODE2 : Proxy disabled, Relay disabled

Now, both nodes belong to same group, which means they are subscribed to same group address. When I published data on the same group address over GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This is as it was expected.

NODE2 is programmed for a button interrupt, which submits a task to system thread with callback function as below

static void pub_presence(struct k_work *work)

    static unsigned char led = 0;
    static unsigned char trans_id = 0;
   
    int err;    

    bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
    net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
    net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);

    err = bt_mesh_model_publish(&root_models[2]);
    if (err) {
        printk("Error in publishing message ");
    }   
 


What I understand is this publishing is over advertising bearer, and NODE1 should not be relaying this packet. But NODE1 relays this packet as well.

 

 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Thu, Dec 7, 2017 at 6:05 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@... wrote:
> I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n*  correctly.
> Thanks for clarification.
>
> However, when I enabled the proxy feature of a node, and disabled its relay
> feature, it relays messages from mesh network as well. I'm using latest
> version  zephyr-1.10.0-rc3.

As I said earlier, when the Proxy feature is enabled, the proxy *should*
be relaying messages from the network to any connected GATT client,
regardless of the Relay feature being enabled or not. If you don't want
your GATT Client to see network traffic, i.e. to only have access to
elements on the GATT Proxy itself, then you should disable the GATT
Proxy feature (have CONFIG_BT_MESH_GATT_PROXY=y but set cfg.gatt_proxy
to BT_MESH_GATT_PROXY_DISABLED).

If you're really seeing advertising to advertising relaying with rc3
(which does have all the latest fixes) there's something very strange
going on, since the logic for this is now quite simple in the code. You
can check this yourself by looking at the bt_mesh_net_relay() function
and the relay_to_adv() helper function that it uses. Both are found in
subsys/bluetooth/host/mesh/net.c.

Johan


Re: Stack check failure with qemu_x86

Luiz Augusto von Dentz
 

Hi Vakul,

On Thu, Dec 7, 2017 at 5:38 AM, Vakul Garg <vakul.garg@nxp.com> wrote:
Hi



I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.



+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y



This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure
of debug connection



Can someone give me pointers how to debug the same?



***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error
addr2line -e zephyr/zephyr.elf 0x00003f6f
/home/vudentz/git/zephyr-github/ext/lib/crypto/tinycrypt/source/hmac_prng.c:187

This is with samples/bluetooth/ipsp sample build with -DBOARD=qemu_x86





Regards



Vakul




_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


--
Luiz Augusto von Dentz


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@corvi.com wrote:
I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n* correctly.
Thanks for clarification.

However, when I enabled the proxy feature of a node, and disabled its relay
feature, it relays messages from mesh network as well. I'm using latest
version zephyr-1.10.0-rc3.
As I said earlier, when the Proxy feature is enabled, the proxy *should*
be relaying messages from the network to any connected GATT client,
regardless of the Relay feature being enabled or not. If you don't want
your GATT Client to see network traffic, i.e. to only have access to
elements on the GATT Proxy itself, then you should disable the GATT
Proxy feature (have CONFIG_BT_MESH_GATT_PROXY=y but set cfg.gatt_proxy
to BT_MESH_GATT_PROXY_DISABLED).

If you're really seeing advertising to advertising relaying with rc3
(which does have all the latest fixes) there's something very strange
going on, since the logic for this is now quite simple in the code. You
can check this yourself by looking at the bt_mesh_net_relay() function
and the relay_to_adv() helper function that it uses. Both are found in
subsys/bluetooth/host/mesh/net.c.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi Johan,
I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n*  correctly. Thanks for clarification.

However, when I enabled the proxy feature of a node, and disabled its relay feature, it relays messages from mesh network as well. I'm using latest version  zephyr-1.10.0-rc3.   


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Thu, Dec 7, 2017 at 4:20 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@... wrote:
> Hi everyone !!!
>
> I'm trying to disable relay feature of node by making these two changes
>
> 1. setting  *CONFIG_BT_MESH_RELAY=n* in the prj.conf file.
>
> 2. static struct bt_mesh_cfg_srv cfg_srv = {
>    * .relay = BT_MESH_RELAY_DISABLED,*

Setting CONFIG_BT_MESH_RELAY=n will actually force the value of
cfg.relay to BT_MESH_RELAY_NOT_SUPPORTED when you initialize mesh, so
trying to set it to disabled shouldn't have any effect. When the value
is NOT_SUPPORTED it can't be changed to any other value at runtime
(which is probably why your attempts with SiLabs don't succeed).

> #if defined(CONFIG_BT_MESH_GATT_PROXY)
>     .gatt_proxy = BT_MESH_GATT_PROXY_ENABLED,
> #else
>     .gatt_proxy = BT_MESH_GATT_PROXY_NOT_SUPPORTED,
> #endif
>     .default_ttl = 5,
>
>     /* network retransmissions with 20ms interval */
>     .net_transmit = BT_MESH_TRANSMIT(5, 20),
>         /* relay retransmissions with 20ms interval */
>     .relay_retransmit = BT_MESH_TRANSMIT(5, 20),
> };
>
> After these two changes, node relays all the messages it receives except
> ones intended for itself.
> What else needs to be done to disable relay feature?
>
> Even Android app by Silicon Labs for bluetooth mesh is not able to disable
> relay feature.

Are you using the latest master branch, since there were fixes for this
feature earlier this week?

Also note that since you're setting gatt_proxy to BT_MESH_GATT_PROXY_ENABLED
it means that the node *is* expected to relay packets between the mesh
network and the GATT Client (however *not* relay packets from the mesh
network back to the mesh network).

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@corvi.com wrote:
Hi everyone !!!

I'm trying to disable relay feature of node by making these two changes

1. setting *CONFIG_BT_MESH_RELAY=n* in the prj.conf file.

2. static struct bt_mesh_cfg_srv cfg_srv = {
* .relay = BT_MESH_RELAY_DISABLED,*
Setting CONFIG_BT_MESH_RELAY=n will actually force the value of
cfg.relay to BT_MESH_RELAY_NOT_SUPPORTED when you initialize mesh, so
trying to set it to disabled shouldn't have any effect. When the value
is NOT_SUPPORTED it can't be changed to any other value at runtime
(which is probably why your attempts with SiLabs don't succeed).

#if defined(CONFIG_BT_MESH_GATT_PROXY)
.gatt_proxy = BT_MESH_GATT_PROXY_ENABLED,
#else
.gatt_proxy = BT_MESH_GATT_PROXY_NOT_SUPPORTED,
#endif
.default_ttl = 5,

/* network retransmissions with 20ms interval */
.net_transmit = BT_MESH_TRANSMIT(5, 20),
/* relay retransmissions with 20ms interval */
.relay_retransmit = BT_MESH_TRANSMIT(5, 20),
};

After these two changes, node relays all the messages it receives except
ones intended for itself.
What else needs to be done to disable relay feature?

Even Android app by Silicon Labs for bluetooth mesh is not able to disable
relay feature.
Are you using the latest master branch, since there were fixes for this
feature earlier this week?

Also note that since you're setting gatt_proxy to BT_MESH_GATT_PROXY_ENABLED
it means that the node *is* expected to relay packets between the mesh
network and the GATT Client (however *not* relay packets from the mesh
network back to the mesh network).

Johan


Disabling Relay feature of a node of bluetooth mesh

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi everyone !!!

I'm trying to disable relay feature of node by making these two changes

1. setting  CONFIG_BT_MESH_RELAY=n in the prj.conf file.

2. static struct bt_mesh_cfg_srv cfg_srv = {
    .relay = BT_MESH_RELAY_DISABLED,
    .beacon = BT_MESH_BEACON_ENABLED,

#if defined(CONFIG_BT_MESH_GATT_PROXY)
    .gatt_proxy = BT_MESH_GATT_PROXY_ENABLED,
#else
    .gatt_proxy = BT_MESH_GATT_PROXY_NOT_SUPPORTED,
#endif
    .default_ttl = 5,

    /* network retransmissions with 20ms interval */
    .net_transmit = BT_MESH_TRANSMIT(5, 20),
        /* relay retransmissions with 20ms interval */
    .relay_retransmit = BT_MESH_TRANSMIT(5, 20),
};

After these two changes, node relays all the messages it receives except ones intended for itself.
What else needs to be done to disable relay feature?

Even Android app by Silicon Labs for bluetooth mesh is not able to disable relay feature.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Stack check failure with qemu_x86

Vakul Garg <vakul.garg@...>
 

Hi

 

I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.

 

+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y

 

This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure of debug connection

 

Can someone give me pointers how to debug the same?

 

***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error

 

 

Regards

 

Vakul

 


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Thank you for the clarification. 

Could you please tell me, what should I do next ?

I need agenda to deeply understand concept of #BluetoothMesh.



On Dec 6, 2017 6:56 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Wed, Dec 06, 2017, Vikrant More wrote:
> static void publish(struct k_work *work)
> {
>
>     static unsigned char onoff=0;
>     static unsigned char tid=0;
>     int err;
>
>     struct net_buf_simple *msg = NET_BUF_SIMPLE(2+4+2);
>
>     bt_mesh_model_msg_init(msg, OP_GEN_ONOFF_SET_UNACK);
>     net_buf_simple_add_u8(msg, onoff=onoff^0x01);
>         net_buf_simple_add_u8(msg, tid++);
>
>     printk("Interrupted....data_send=%u\n\r",onoff);
>
>     *root_models[2]*.pub->msg=msg;

This is not safe since the publishing buffer is not expected to be
allocated on the stack. It will cause a crash as soon as the Publish
Retransmit state is set to a non-zero value. I pointed this out earlier
to Steve and also tried to document it better:

https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/008457.html

So in your case you'd want to create the buffer when you define the
publication struct, i.e. something like:

static struct bt_mesh_model_pub pub = {
        .msg = NET_BUF_SIMPLE(2+4+2),
};

And then before publishing you'd do the same bt_mesh_model_msg_init()
and net_buf_simple_add_u8() calls as you do now.

> When I publish using  *root_models[2] *then function
> bt_mesh_model_publish(struct bt_mesh_model *model) from
> zephyr/subsys/bluetooth/host/mesh/access.c
> execute properly after pressing the Button1 on nRF52840-PDK.
>
> root_models[2] is server model.
>
> Its publish address assigned by provisioner = 0xC000
> It is subscribed to address = 0xC001
>
> So all other nodes not changed their LED1 status when I pressed Button1
> from any one of the Board since others are subscribed to 0xC001.
>
> But when I hard-coded ctx.addr = 0xC001; in bt_mesh_model_publish(struct
> bt_mesh_model *model) then ohter boards start to toggle LED1.

This looks like an issue with the provisioner (or how you use it) since
it seems it should also be setting the publication address to 0xc0001.

> So I used root_model[4] i.e BT_MESH_MODEL_ID_GEN_ONOFF_CLI.
>
> In this case, after pressing button, function bt_mesh_model_publish() returns
> error as -> bt_mesh_model_publish: err:-49
>
> On investigating, I found that this is because of
>
> if (pub->addr == BT_MESH_ADDR_UNASSIGNED) {
>         return -EADDRNOTAVAIL;
>     }
>
> That means Silicon Labs MESH APP does not assign any Public address to this
> client model.
> Ideally it should be 0xC001 since other NODEs are subscribed to it. Am I
> right ?

Yes, sounds correct to me, i.e. this is an issue on the
provisioner/configuration client side.

Johan


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Johan Hedberg
 

Hi Vikrant,

On Wed, Dec 06, 2017, Vikrant More wrote:
static void publish(struct k_work *work)
{

static unsigned char onoff=0;
static unsigned char tid=0;
int err;

struct net_buf_simple *msg = NET_BUF_SIMPLE(2+4+2);

bt_mesh_model_msg_init(msg, OP_GEN_ONOFF_SET_UNACK);
net_buf_simple_add_u8(msg, onoff=onoff^0x01);
net_buf_simple_add_u8(msg, tid++);

printk("Interrupted....data_send=%u\n\r",onoff);

*root_models[2]*.pub->msg=msg;
This is not safe since the publishing buffer is not expected to be
allocated on the stack. It will cause a crash as soon as the Publish
Retransmit state is set to a non-zero value. I pointed this out earlier
to Steve and also tried to document it better:

https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/008457.html

So in your case you'd want to create the buffer when you define the
publication struct, i.e. something like:

static struct bt_mesh_model_pub pub = {
.msg = NET_BUF_SIMPLE(2+4+2),
};

And then before publishing you'd do the same bt_mesh_model_msg_init()
and net_buf_simple_add_u8() calls as you do now.

When I publish using *root_models[2] *then function
bt_mesh_model_publish(struct bt_mesh_model *model) from
zephyr/subsys/bluetooth/host/mesh/access.c
execute properly after pressing the Button1 on nRF52840-PDK.

root_models[2] is server model.

Its publish address assigned by provisioner = 0xC000
It is subscribed to address = 0xC001

So all other nodes not changed their LED1 status when I pressed Button1
from any one of the Board since others are subscribed to 0xC001.

But when I hard-coded ctx.addr = 0xC001; in bt_mesh_model_publish(struct
bt_mesh_model *model) then ohter boards start to toggle LED1.
This looks like an issue with the provisioner (or how you use it) since
it seems it should also be setting the publication address to 0xc0001.

So I used root_model[4] i.e BT_MESH_MODEL_ID_GEN_ONOFF_CLI.

In this case, after pressing button, function bt_mesh_model_publish() returns
error as -> bt_mesh_model_publish: err:-49

On investigating, I found that this is because of

if (pub->addr == BT_MESH_ADDR_UNASSIGNED) {
return -EADDRNOTAVAIL;
}

That means Silicon Labs MESH APP does not assign any Public address to this
client model.
Ideally it should be 0xC001 since other NODEs are subscribed to it. Am I
right ?
Yes, sounds correct to me, i.e. this is an issue on the
provisioner/configuration client side.

Johan


Re: MQTT-SN support

Paul Sokolovsky
 

Hello Flavio,

On Mon, 4 Dec 2017 08:51:09 -0200
Flavio Arieta <flavioarieta@gmail.com> wrote:

I was studying the MQTT protocol and got in doubt why the rtos
implements it instead of MQTT-SN.
It doesn't implement it "instead", it just implements it. Zephyr is a
general-purpose inclusive (RT)OS ;-).

There is an email from April 2016 on the Zephyr-devel mailing list
saying that there are little dependencies to implement the MQTT-SN
and on the roadmap it could be implemented first, then CoAP and
finally MQTT itself. Is there any updates about this apart from the
single reply that it received back in 2016?
How things get added/implemented in Zephyr is based on the interests of
the stakeholders (i.e. parties which are actively involved in the
development) and the community (which contribute to the development).

I'm personally not surprised that MQTT-SN isn't implemented while MQTT
is - I never heard of MQTT-SN used in the wild, while "everyone" uses
MQTT (and real-world usage isn't related to technical/theoretical
merits, as we know).

Another point that there's no need to "implement" some protocol
specifically for Zephyr - there're certainly existing libs which
implement MQTT-SN, so they just need to be *ported* to Zephyr. That
used to be complicated, as such libs likely use standard well-known
APIs for networking, like BSD Sockets, but now Zephyr offer such an
API too.


Summing up, Zephyr should already offers various choices for almost any
protocol: a) use a close analog; b) port existing lib; c) develop
optimized support specifically for Zephyr.

If you're interested in MQTT-SN, definitely feel free to give a try to
one of the last 2 choices.


Thanks,
Flávio Arieta Netto.
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Hello Sir,

I have attached my main.c with this email. (from Zephyr Mesh Demo)

This main.c is mostly inspired from information provided by Steve Brown. 

Please check it.

Here,

root_models[2] is BT_MESH_MODEL_ID_GEN_ONOFF_SRV
root_models[4] is BT_MESH_MODEL_ID_GEN_ONOFF_CLI

------------------------------------------------------------------------------------------------------------------------------------------
static void publish(struct k_work *work)
{

    static unsigned char onoff=0;
    static unsigned char tid=0;
    int err;

    struct net_buf_simple *msg = NET_BUF_SIMPLE(2+4+2);

    bt_mesh_model_msg_init(msg, OP_GEN_ONOFF_SET_UNACK);
    net_buf_simple_add_u8(msg, onoff=onoff^0x01);
        net_buf_simple_add_u8(msg, tid++);

    printk("Interrupted....data_send=%u\n\r",onoff);

    root_models[2].pub->msg=msg;

    err = bt_mesh_model_publish(&root_models[2]);
    if (err) {
        printk("bt_mesh_model_publish: err: %d\n\r", err);
    }

}
-----------------------------------------------------------------------------------------------------------------------------------------

When I publish using  root_models[2] then function  bt_mesh_model_publish(struct bt_mesh_model *model) from zephyr/subsys/bluetooth/host/mesh/access.c 
execute properly after pressing the Button1 on nRF52840-PDK.

root_models[2] is server model.

Its publish address assigned by provisioner = 0xC000
It is subscribed to address = 0xC001

So all other nodes not changed their LED1 status when I pressed Button1 from any one of the Board since others are subscribed to 0xC001.

But when I hard-coded ctx.addr = 0xC001; in bt_mesh_model_publish(struct bt_mesh_model *model) then ohter boards start to toggle LED1.

I know this is wrong way to publish since we have to use client model to publish anything.
------------------------------------------------------------------------------------------------------------------------------------------

So I used root_model[4] i.e BT_MESH_MODEL_ID_GEN_ONOFF_CLI.

In this case, after pressing button, function bt_mesh_model_publish() returns error as -> bt_mesh_model_publish: err:-49

On investigating, I found that this is because of

if (pub->addr == BT_MESH_ADDR_UNASSIGNED) {
        return -EADDRNOTAVAIL;
    } 

That means Silicon Labs MESH APP does not assign any Public address to this client model.
Ideally it should be 0xC001 since other NODEs are subscribed to it. Am I right ?

--------------------------------------------------------------------------------------------------------------------------------------------

Am I on right track ?

When I follow Steve's code & increase .net_transmit = BT_MESH_TRANSMIT(5, 20) upto 5, then reliability is almost 100%.

Plus THREAD calls bt_mesh_model_publish( ) on every click even if I pressed button multiple times
in short period of time.

I will appreciate your suggestions if there are any. Please guide me what to do next.
I thoroughly want to understand everything before building my final application.

Thank You for your support !!


On Tue, Dec 5, 2017 at 11:09 PM, Vikrant More <vikrant8051@...> wrote:
I have added bt_mesh_model_publish( ) in thread which starts to execute after getting interrupt from button. But when I click button multiple times in very short period of time then only thread executes but 
bt_mesh_model_publish( ) never get called.



On Dec 5, 2017 10:32 PM, "Vikrant More" <vikrant8051@...> wrote:
Currently noob like me don't known how to correctly fine tuned or configure or write code from scratch using Zephyr so that it will exactly work like Nordic Semiconductor Mesh Light_Switch Demo. 

Hence I am requesting you to provide simple demo for nrf52840-PDK board. To find out what nordic has done differently, person should have knowledge of entire stack  & currently you are only one who knows everything. 

Coding style in Zephyr Mesh & nordic Mesh SDK is not simple C. It is objective C, so very difficult to visualize everything.

Plus #NordicSemiconductor code is very complicated compare to your coding style. 

I agree with you that coexistence of GATT & ADV Bearer may be reason of less reliability of data transfer.

So currently, I can do is wait till nordic implement GATT Bearer in their Mesh SDK to check overall performance or till they release Android App with ADV-provisioner utility.


On Dec 5, 2017 9:19 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
> But as per my testing, zephyr publishing reliability is not good even if I
> call bt_mesh_model_publish() from thread which wakes up on interrupt.

This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan




Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

I have added bt_mesh_model_publish( ) in thread which starts to execute after getting interrupt from button. But when I click button multiple times in very short period of time then only thread executes but 
bt_mesh_model_publish( ) never get called.



On Dec 5, 2017 10:32 PM, "Vikrant More" <vikrant8051@...> wrote:
Currently noob like me don't known how to correctly fine tuned or configure or write code from scratch using Zephyr so that it will exactly work like Nordic Semiconductor Mesh Light_Switch Demo. 

Hence I am requesting you to provide simple demo for nrf52840-PDK board. To find out what nordic has done differently, person should have knowledge of entire stack  & currently you are only one who knows everything. 

Coding style in Zephyr Mesh & nordic Mesh SDK is not simple C. It is objective C, so very difficult to visualize everything.

Plus #NordicSemiconductor code is very complicated compare to your coding style. 

I agree with you that coexistence of GATT & ADV Bearer may be reason of less reliability of data transfer.

So currently, I can do is wait till nordic implement GATT Bearer in their Mesh SDK to check overall performance or till they release Android App with ADV-provisioner utility.


On Dec 5, 2017 9:19 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
> But as per my testing, zephyr publishing reliability is not good even if I
> call bt_mesh_model_publish() from thread which wakes up on interrupt.

This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan



Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Luiz Augusto von Dentz
 

Hi Priyanka,

On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hello

My test set up for IPv6 over BLE is following :

At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as
ble host (flashed with zephyr sample IPSP).
I assume hci_blackbox is not a zephyr based controller is it?

At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble
controller attached to Linux host.


[Kw41z (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
controller)+Linux host]

Issue with testing IPv6 over BLE :

Once the BLE connection is established, within few seconds BLE controller
gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or
both. Often it is BLE controller that gets disconnected within few seconds.
Restarting zephyr might enable establishing the connection once again, but
then ble controller goes down immediately.
Im not sure if will be able to help in case the controller is not
really zephyr based in the other hand we should be able to fix the
host crash if you provide some traces when that happens.

After that, I should disconnect the boards and connect again (via usb
connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is
different (handle 65, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection or
connection terminated by local host
I guess with Zephyr the controller crashes and restart using the same
handle, while with Linux it manages to work fine, perhaps this is
because zephyr attempts to use the host flow control?


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Currently noob like me don't known how to correctly fine tuned or configure or write code from scratch using Zephyr so that it will exactly work like Nordic Semiconductor Mesh Light_Switch Demo. 

Hence I am requesting you to provide simple demo for nrf52840-PDK board. To find out what nordic has done differently, person should have knowledge of entire stack  & currently you are only one who knows everything. 

Coding style in Zephyr Mesh & nordic Mesh SDK is not simple C. It is objective C, so very difficult to visualize everything.

Plus #NordicSemiconductor code is very complicated compare to your coding style. 

I agree with you that coexistence of GATT & ADV Bearer may be reason of less reliability of data transfer.

So currently, I can do is wait till nordic implement GATT Bearer in their Mesh SDK to check overall performance or till they release Android App with ADV-provisioner utility.


On Dec 5, 2017 9:19 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
> But as per my testing, zephyr publishing reliability is not good even if I
> call bt_mesh_model_publish() from thread which wakes up on interrupt.

This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan

2301 - 2320 of 2659