Date   

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


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

Johan Hedberg
 

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


Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Priyanka
 

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

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.

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

On Linux PC
--------------
$ sudo hciattach ttyACMx any 115200 noflow sleep
Device setup complete

$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 32 state 1 lm MASTER


$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 65 state 8 lm MASTER

$ sudo hcitool conn

Connections:


$ sudo hcitool lescan

LE Scan ...

00:04:9F:00:00:15 (unknown)

00:04:9F:00:00:15 Test IPSP node

04:52:C7:64:6C:65 (unknown)


$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 96 state 1 lm MASTER

$ sudo hcitool conn

Connections:

$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 128 state 1 lm MASTER

$ sudo hcitool conn

Connections:



Zephyr (IPSP)
--------------------
During that very short span of connection, ping does not pass, there is a ping time out and then ble controller goes down.

And it prints error

[bt] [ERR] read_payload: Not enough space in buffer


net> iface

Interface 0x2000a020 (Bluetooth)
================================
Link addr : 00:04:9F:00:00:15
MTU       : 1280
IPv6 unicast addresses (max 3):
        2001:db8::1 manual preferred infinite
        fe80::4:9fff:fe00:15 autoconf preferred infinite
IPv6 multicast addresses (max 2):
        ff84::2
        ff02::1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 9178
IPv6 retransmit timer    : 0
net> ping 2001:db8::2
Sent a ping to 2001:db8::2
[bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006db4 len 57
[bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006bf8 len 59
[bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59 credits 3
[bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
[bt] [DBG] bt_conn_send_cb: (0x20001210) conn handle 32 buf len 63 cb 0x00000000
[bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040 sent 57 total_len 57
[bt] [DBG] bt_conn_process_tx: (0x200006f8) conn 0x200008d4
[bt] [DBG] send_buf: (0x200006f8) conn 0x200008d4 buf 0x20006bf8 len 63
[bt] [DBG] send_frag: (0x200006f8) conn 0x200008d4 buf 0x20006bf8 len 63 flags 0x00
[bt] [DBG] bt_conn_notify_tx: (0x200006f8) conn 0x200008d4
[bt] [DBG] add_pending_tx: (0x200006f8) conn 0x200008d4 cb 0x00000000
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8) Adding conn 0x200008d4 to poll list
Ping timeout

btmon log shows for specific handle : remote user terminated connection or connection terminated by local host

$ sudo btmon

< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                             [hci0] 56.603853
        Handle: 32
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.605669
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 56.623140
        Num handles: 1
        Handle: 32
        Count: 0
> HCI Event: Disconnect Complete (0x05) plen 4                                                                             [hci0] 56.623895
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2



$ sudo btmon
Bluetooth monitor ver 5.37
= New Index: 00:60:37:00:00:16 (BR/EDR,UART,hci0)                                                                           [hci0] 0.420344
= Open Index: 00:60:37:00:00:16                                                                                             [hci0] 0.420346
= Index Info: 00:60:37:00:00:16 (NXP Semiconductors (formerly Philips Semiconductors))                                      [hci0] 0.420347
> HCI Event: LE Meta Event (0x3e) plen 19                                                                                  [hci0] 25.087469
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 32
        Role: Master (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:04:9F:00:00:15 (Freescale Semiconductor)
        Connection interval: 18.75 msec (0x000f)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 32000 msec (0x0c80)
        Master clock accuracy: 0x00
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                           [hci0] 25.087749
        Handle: 32
@ Device Connected: 00:04:9F:00:00:15 (1) flags 0x0000
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 25.090858
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12                                                                                  [hci0] 25.160087
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 32
        Features: 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
< ACL Data TX: Handle 32 flags 0x00 dlen 7                                                                                 [hci0] 25.160299
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 25.197003
        Num handles: 1
        Handle: 32
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                  [hci0] 25.216210
      LE Data Length Change (0x07)
        Handle: 32
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> ACL Data RX: Handle 32 flags 0x02 dlen 7                                                                                 [hci0] 25.291092
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 65
< ACL Data TX: Handle 32 flags 0x00 dlen 11                                                                                [hci0] 25.291176
      ATT: Read By Group Type Request (0x10) len 6
        Handle range: 0x0001-0xffff
        Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 25.309459
        Num handles: 1
        Handle: 32
        Count: 1
< HCI Command: LE Create Connection (0x08|0x000d) plen 25                                                                  [hci0] 56.599500
        Scan interval: 2.500 msec (0x0004)
        Scan window: 2.500 msec (0x0004)
        Filter policy: White list is not used (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:04:9F:00:00:15 (Freescale Semiconductor)
        Own address type: Public (0x00)
        Min connection interval: 18.75 msec (0x000f)
        Max connection interval: 18.75 msec (0x000f)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
        Min connection length: 0.625 msec (0x0001)
        Max connection length: 0.625 msec (0x0001)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.603808
      LE Create Connection (0x08|0x000d) ncmd 1
        Status: Success (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                             [hci0] 56.603853
        Handle: 32
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.605669
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 56.623140
        Num handles: 1
        Handle: 32
        Count: 0
> HCI Event: Disconnect Complete (0x05) plen 4                                                                             [hci0] 56.623895
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2

> HCI Event: Disconnect Complete (0x05) plen 4                                                                            [hci0] 495.817382
        Status: Success (0x00)
        Handle: 96
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2


< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                          [hci0] 559.455648
        Handle: 128
@ Device Connected: 00:04:9F:00:00:15 (1) flags 0x0000
> HCI Event: Command Status (0x0f) plen 4                                                                                 [hci0] 559.458269
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)

> HCI Event: LE Meta Event (0x3e) plen 12                                                                                 [hci0] 559.552125
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 128
        Features: 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
< ACL Data TX: Handle 128 flags 0x00 dlen 7                                                                               [hci0] 559.552334
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 559.589004
        Num handles: 1
        Handle: 128
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                 [hci0] 559.608138
      LE Data Length Change (0x07)
        Handle: 128
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> ACL Data RX: Handle 128 flags 0x02 dlen 7                                                                               [hci0] 559.683143
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 65
< ACL Data TX: Handle 128 flags 0x00 dlen 11                                                                              [hci0] 559.683325
      ATT: Read By Group Type Request (0x10) len 6
        Handle range: 0x0001-0xffff
        Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 559.701758
        Num handles: 1
        Handle: 128
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                 [hci0] 564.727345
      LE Remote Connection Parameter Request (0x06)
        Handle: 128
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
< HCI Command: LE Remote Connection Parameter Request Reply (0x08|0x0020) plen 14                                         [hci0] 564.727418
        Handle: 128
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
@ New Conn Param: 00:04:9F:00:00:15 (1) hint 1 min 0x0018 max 0x0028 latency 0x0000 timeout 0x0c80
> HCI Event: Command Complete (0x0e) plen 6                                                                               [hci0] 564.731202
      LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
        Status: Success (0x00)
        Handle: 128
> HCI Event: LE Meta Event (0x3e) plen 10                                                                                 [hci0] 564.971598
      LE Connection Update Complete (0x03)
        Status: Success (0x00)
        Handle: 128
        Connection interval: 30.00 msec (0x0018)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 32000 msec (0x0c80)
< ACL Data TX: Handle 128 flags 0x00 dlen 18                                                                              [hci0] 577.871547
      LE L2CAP: LE Connection Request (0x14) ident 1 len 10
        PSM: 35 (0x0023)
        Source CID: 64
        MTU: 1280
        MPS: 230
        Credits: 10
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 577.902129
        Num handles: 1
        Handle: 128
        Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 18                                                                              [hci0] 578.113503
      LE L2CAP: LE Connection Response (0x15) ident 1 len 10
        Destination CID: 64
        MTU: 1280
        MPS: 65
        Credits: 20
        Result: Connection successful (0x0000)
< ACL Data TX: Handle 128 flags 0x00 dlen 46                                                                              [hci0] 578.119173
      Channel: 64 len 42 [PSM 35 mode 0] {chan 2}
        28 00 79 4b 00 16 3a 00 05 02 00 00 01 00 8f 00  (.yK..:.........
        6f 74 00 00 00 01 04 00 00 00 ff 02 00 00 00 00  ot..............
        00 00 00 00 00 01 ff 00 00 16                    ..........      
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.142511
        Num handles: 1
        Handle: 128
        Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 50                                                                              [hci0] 578.211240
      Channel: 64 len 46 [PSM 35 mode 0] {chan 2}
        2c 00 7b 3b 3a 01 88 00 b2 32 20 00 00 00 fe 80  ,.{;:....2 .....
        00 00 00 00 00 00 02 60 37 ff fe 00 00 16 02 02  .......`7.......
        00 60 37 ff fe 00 00 16 00 00 00 00 00 00        .`7...........  
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.232753
        Num handles: 1
        Handle: 128
        Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 39                                                                              [hci0] 578.236748
      Channel: 64 len 35 [PSM 35 mode 0] {chan 2}
        21 00 7b 49 3a 02 01 ff 00 00 15 87 00 0c 2c 2a  !.{I:.........,*
        52 a7 7a fe 80 00 00 00 00 00 00 00 04 9f ff fe  R.z.............
        00 00 15                                         ...             
< ACL Data TX: Handle 128 flags 0x00 dlen 39                                                                              [hci0] 578.263150
      Channel: 64 len 35 [PSM 35 mode 0] {chan 2}
        21 00 7b 49 3a 02 01 ff 00 00 16 87 00 43 9b 00  !.{I:........C..
        00 00 00 fe 80 00 00 00 00 00 00 02 60 37 ff fe  ............`7..
        00 00 16                                         ...             
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.292505
        Num handles: 1
        Handle: 128
        Count: 1


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

samples/bluetooth/ipsp$ prj.conf

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NETWORKING=y
CONFIG_NET_IPV6=y
CONFIG_NET_IPV4=n
CONFIG_NET_UDP=y
CONFIG_NET_TCP=y
CONFIG_TEST_RANDOM_GENERATOR=y
CONFIG_NET_LOG=y
CONFIG_NET_L2_BT=y
CONFIG_NET_DEBUG_L2_BT=y
CONFIG_SYS_LOG_SHOW_COLOR=y
CONFIG_INIT_STACKS=y
CONFIG_NET_STATISTICS=y
CONFIG_NET_PKT_RX_COUNT=10
CONFIG_NET_PKT_TX_COUNT=10
CONFIG_NET_BUF_RX_COUNT=20
CONFIG_NET_BUF_TX_COUNT=20
CONFIG_NET_IF_UNICAST_IPV6_ADDR_COUNT=3
CONFIG_NET_IF_MCAST_IPV6_ADDR_COUNT=2
CONFIG_NET_MAX_CONTEXTS=6

CONFIG_NET_SHELL=y
CONFIG_BT_SHELL=y

CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
CONFIG_NET_APP_PEER_IPV6_ADDR="2001:db8::2"
CONFIG_NET_APP_BT_NODE=y

CONFIG_NET_L2_ETHERNET=n
CONFIG_ETH_MCUX=n
CONFIG_ETH_MCUX_0=n

#CONFIG_BT_DEBUG_HCI_DRIVER=y
#CONFIG_BT_DEBUG_HCI_CORE=y

CONFIG_BT_PRIVACY=n
#CONFIG_BT_DEBUG=y
#CONFIG_BT_DEBUG_HCI_CORE=n
CONFIG_BT_DEBUG_CONN=y
CONFIG_BT_DEBUG_KEYS=y
CONFIG_BT_DEBUG_L2CAP=y
CONFIG_BT_DEBUG_SMP=y
CONFIG_BT_DEBUG_SDP=y


Thanks

Priyanka


Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Hello,

I need simple clone of of "Light_Switch" demo (part of nordic semiconductor mesh SDK) using Zephyr.
In that demo, we can control Led1 on Servers using publishing data from client. Reliability is 100% even entire demo is based on only ADV-Bearer.
They used one client & 3 Servers. Client itself acts like provisioner.

Unfortunately, Nordic uses only ADV-Bearer & so we can't use available Silicon Labs Mesh App as provisioner.

So I shift to Zephyr since at least I can test working of Mesh using Provisioner APP.

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.

I want to publish 0 and 1 (toggle) after pressing button on one device to all other available nodes in vicinity. (individually using Unicast addresses & for many using Group address  )

So please release such full working demo like Nordic using Zephyr OS.
 
Or help me in details so that I can release behalf on Zephyr Community.

Thank You!!


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

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


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

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


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

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

2381 - 2400 of 2733