Date   

L2CAP errors on linux while running 6loble

Vakul Garg <vakul.garg@...>
 

Hi

 

I am transferring UDP packets over 6loble link between a zephyr endpoint and linux box.

On my linux box, I see errors:

 

[root@lti ~]# dmesg

[416975.584892] Bluetooth: Too much LE L2CAP data received

[416976.365482] Bluetooth: Too much LE L2CAP data received

[416977.171158] Bluetooth: Frame is too long (len 186, expected len 68)

[416977.566971] Bluetooth: Too much LE L2CAP data received

 

Can someone please provide some hint what could I be doing wrong?

I am using linux kernel version 4.13.12.

 

Regards

 

Vakul


Silicon Labs Bluetooth Mesh App compatible Zephyr mesh example for nRF52840-PDK

Vikrant More <vikrant8051@...>
 

I wanna control Leds on nRF52840-PDK board using Silicon Labs Bluetooth Mesh App.
 
Is there any one who has modify $zephyr/samples/bluetooth/mesh example so that it will get compatible for Silicon Labs Bluetooth Mesh App ??

🤔


Re: Help needed to setup 6loble using IPSP sample

Vakul Garg <vakul.garg@...>
 

Hi Johan

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@intel.com]
Sent: Tuesday, November 21, 2017 1:56 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help needed to setup 6loble using IPSP sample

Hi Vakul,

On Tue, Nov 21, 2017, Vakul Garg wrote:
Have you verified that the handle value 32 is valid, i.e. the
controller gave that in a prior LE Connection Complete event?
The linux console shows up connection handle 32 has been connected.
The connection handle is completely local to the device, so what you have on
the Linux side has no relevance to Zephyr (i.e. the handles can, and often will
be different).

[bt] [ERR] le_remote_feat_complete: Unable to lookup conn for handle
32 [bt] [ERR] hci_acl: Unable to find conn for handle 32 [bt] [ERR]
le_data_len_change: Unable to lookup conn for handle 32
I don't see any connection complete event in the logs prior to this. So it's not a
surprise that the host complains of an unknown handle value, i.e. this looks
like some kind of misbehavior by the controller.
My BLE controller firmware experts told me that privacy feature has some errata on my hardware.
I encountered the error even when zephyr was compiled without CONFIG_BT_PRIVACY=y.
So, I patched the hci_core.c code like this to make it work.
Can you please comment?

diff --git a/subsys/bluetooth/host/hci_core.c b/subsys/bluetooth/host/hci_core.c
index e02d5ff6a..e00ad5f37 100644
--- a/subsys/bluetooth/host/hci_core.c
+++ b/subsys/bluetooth/host/hci_core.c
@@ -3532,7 +3532,8 @@ static int le_set_event_mask(void)
mask |= BT_EVT_MASK_LE_ADVERTISING_REPORT;

if (IS_ENABLED(CONFIG_BT_CONN)) {
- if (BT_FEAT_LE_PRIVACY(bt_dev.le.features)) {
+ if (IS_ENABLED(CONFIG_BT_PRIVACY) &&
+ BT_FEAT_LE_PRIVACY(bt_dev.le.features)) {
mask |= BT_EVT_MASK_LE_ENH_CONN_COMPLETE;
} else {
mask |= BT_EVT_MASK_LE_CONN_COMPLETE;
@@ -3673,7 +3674,8 @@ static int le_init(void)
}

#if defined(CONFIG_BT_SMP)
- if (BT_FEAT_LE_PRIVACY(bt_dev.le.features)) {
+ if (IS_ENABLED(CONFIG_BT_PRIVACY) &&
+ BT_FEAT_LE_PRIVACY(bt_dev.le.features)) {
struct bt_hci_rp_le_read_rl_size *rp;
struct net_buf *rsp;




Johan


how to configure node for subscribe & public address

Vikrant More <vikrant8051@...>
 

After connecting with Device we get following options while configuring the device.

[config: Target = 0100]# h
Client Configuration Menu
Available commands:
  target <unicast>                          Set target node to configure
  get-composition [<page_num>]              Get Composition Data
  add-netkey <net_idx>                      Add network key
  del-netkey <net_idx>                      Delete network key
  add-appkey <app_idx>                      Add application key
  del-appkey <app_idx>                      Delete application key
  bind <ele_idx> <app_idx> <mod_id> [cid]   Bind app key to a model
  set-ttl <ttl>                             Set default TTL
  get-ttl                                   Get default TTL
  set-pub <ele_addr> <pub_addr> <app_idx> <period (step|res)> <model> Set publication
  back                                      Back to main menu
  help                                      Config Commands


But I am unable to find option which add subscription addresses.

How to properly add publish addresses ??

What is need to add publish address in every node if every node has subscription devices list ?

As per my understanding every node of MESH, can receive every packet on n/w. If sender address from that packet is not matching with address in subscription list then that packet is redundant for that node. It is understandable. Then what is need of creating publish addresses list for every node ? Let any device to broadcast any packet if it want to do it.



Re: Help needed to setup 6loble using IPSP sample

Vakul Garg <vakul.garg@...>
 

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@intel.com]
Sent: Tuesday, November 21, 2017 1:56 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help needed to setup 6loble using IPSP sample

Hi Vakul,

On Tue, Nov 21, 2017, Vakul Garg wrote:
Have you verified that the handle value 32 is valid, i.e. the
controller gave that in a prior LE Connection Complete event?
The linux console shows up connection handle 32 has been connected.
The connection handle is completely local to the device, so what you have on
the Linux side has no relevance to Zephyr (i.e. the handles can, and often will
be different).

[bt] [ERR] le_remote_feat_complete: Unable to lookup conn for handle
32 [bt] [ERR] hci_acl: Unable to find conn for handle 32 [bt] [ERR]
le_data_len_change: Unable to lookup conn for handle 32
I don't see any connection complete event in the logs prior to this. So it's not a
surprise that the host complains of an unknown handle value, i.e. this looks
like some kind of misbehavior by the controller.
Can you please elaborate? On issuing 'connect' command at linux host, I get only mostly the error prints telling that connection handle can't be found.
Did my linux host even try connection establishment sequence or did it assume (say from previous run) that a certain connection already exists and tried to use it again due to which zephyr said handle does not exist?


Johan


Re: Help needed to setup 6loble using IPSP sample

Johan Hedberg
 

Hi Vakul,

On Tue, Nov 21, 2017, Vakul Garg wrote:
Have you verified that the handle value 32 is valid, i.e. the
controller gave that in a prior LE Connection Complete event?
The linux console shows up connection handle 32 has been connected.
The connection handle is completely local to the device, so what you
have on the Linux side has no relevance to Zephyr (i.e. the handles can,
and often will be different).

[bt] [ERR] le_remote_feat_complete: Unable to lookup conn for handle 32
[bt] [ERR] hci_acl: Unable to find conn for handle 32
[bt] [ERR] le_data_len_change: Unable to lookup conn for handle 32
I don't see any connection complete event in the logs prior to this. So
it's not a surprise that the host complains of an unknown handle value,
i.e. this looks like some kind of misbehavior by the controller.

Johan


Re: Help needed to setup 6loble using IPSP sample

Vakul Garg <vakul.garg@...>
 

Hi Johan

Let me first admit that I am using BLE for first time and might be missing some basic step.

I simply followed steps from IPSP sample's README. The steps work fine on the older commit I mentioned.

Have you verified that the handle value 32 is valid, i.e. the controller gave that
in a prior LE Connection Complete event?
The linux console shows up connection handle 32 has been connected.

Here are the zephyr logs you requested.
I have used:

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

Turning CONFIG_BT_DEBUG_HCI_CORE=y causes 'hcitool lescan' to keep waiting almost infinitely.
Also 'hcitool lecc' keeps waiting. Please let me know if you need something more.

Regards,
Vakul

[bt] [DBG] hci_tx_thread: (0x200006f8) Started
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] hci_tx_thread: (0x200006f8) Calling k_poll with 2 events
[bt] [DBG] bt_hci_cmd_create: (0x20001998) opcode 0x0c03 param_len 0
[bt] [DBG] bt_hci_cmd_create: (0x20001998) buf 0x20004814
[bt] [DBG] bt_hci_cmd_send_sync: (0x20001998) buf 0x20004814 opcode 0x0c03 len 3
[bt] [DBG] process_events: (0x200006f8) count 2
[bt] [DBG] process_events: (0x200006f8) ev->state 4
[bt] [DBG] send_cmd: (0x200006f8) calling net_buf_get
[bt] [DBG] send_cmd: (0x200006f8) calling sem_take_wait
[bt] [DBG] send_cmd: (0x200006f8) Sending command 0x0c03 (buf 0x20004814) to driver
[bt] [DBG] bt_send: (0x200006f8) buf 0x20004814 len 3 type 0
[bt] [DBG] process_events: (0x200006f8) ev->state 0
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] hci_t[bt] [DBG] bt_buf_get_cmd_complete: (0x200006f8) sent_cmd 0x20004814
x_thread: (0x200006f8) Calling k_poll with 2 events
[bt] [DBG] bt_hci_cmd_send_sync: (0x20001998) opcode 0x0c03 status 0x00
[bt] [DBG] hci_reset_complete: (0x20001998) status 14
[bt] [DBG] bt_hci_cmd_create: (0x20001998) opcode 0x1003 param_len 0
[bt] [DBG] bt_hci_cmd_create: (0x20001998) buf 0x20004878
[bt] [DBG] bt_hci_cmd_send_sync: (0x20001998) buf 0x20004878 opcode 0x1003 len 3
[bt] [DBG] process_events: (0x200006f8) count 2
[bt] [DBG] process_events: (0x200006f8) ev->state 4
[bt] [DBG] send_cmd: (0x200006f8) calling net_buf_get
[bt] [DBG] send_cmd: (0x200006f8) calling sem_take_wait
[bt] [DBG] bt_hci_cmd_send_sync: (0x20001998) opcode 0x1003 status 0x6a
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait
shell> delaying
shell> delaying
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait
shell> delaying
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [WRN] hci_vs_init: Vendor HCI extensions not available
[bt] [INF] show_dev_info: Identity: 00:60:37:00:00:16 (public)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x000b, manufacturer 0x0025
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0x0123
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0004
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0006
[bt] [DBG] bt_smp_init: (0x20001998) LE SC enabled
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0005
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_smp_pkey_ready: (0x200003b4)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait
[bt] [ERR] le_remote_feat_complete: Unable to lookup conn for handle 32
[bt] [ERR] hci_acl: Unable to find conn for handle 32
[bt] [ERR] le_data_len_change: Unable to lookup conn for handle 32

shell>



-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@intel.com]
Sent: Tuesday, November 21, 2017 1:03 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help needed to setup 6loble using IPSP sample

Hi Vakul,

On Tue, Nov 21, 2017, Vakul Garg wrote:
I am using frdm-kw41z (running hci_blackbox firmware from nxp) stacked
over frdm-k64f running zephyr sample IPSP.
In this config, frdm-kw41z acts as bluetooth controller and frdm-k64f acts
bluetooth host.

On the peer end, a linux machine is attached with another frdm-kw41z with
same hci_blackbox firmware as above (but with different BD address).

On, running 'hcitool lescan' on linux machine, it can detect the peer IPSP
node.
However, running 'hcitool lecc <ipsp node bd address>' causes following
error prints on zephyr console.

net> [bt] [ERR] hci_acl: Unable to find conn for handle 32
[bt] [ERR] le_data_len_change: Unable to lookup conn for handle 32
net> [bt] [ERR] hci_num_completed_packets: No connection for handle 32

My colleague (Maureen - thanks !!) bisected the git and found that following
commit is to blame.
Indeed, removing it solves the issue.

----------------------------------------------------------------------
---------------- commit 56f79f817e679857e385a14f9a7e9b951dbc626e
Author: Johan Hedberg
<johan.hedberg@intel.com<mailto:johan.hedberg@intel.com>>
Date: Thu Oct 5 09:43:56 2017 +0300

Bluetooth: Add support for Link Layer Privacy
----------------------------------------------------------------------
----------------

Can someone please advise me if I am missing some step or is it a bug that
needs to be logged?
The same issue causes problem with other Bluetooth examples such
peripheral_hr etc.

Have you verified that the handle value 32 is valid, i.e. the controller gave that
in a prior LE Connection Complete event? It would help investigate the issue if
you could get the entire log and also the HCI log of what's happening. It's not
clear to me how the LL Privacy patch could influence this.

Johan


Re: Help needed to setup 6loble using IPSP sample

Johan Hedberg
 

Hi Vakul,

On Tue, Nov 21, 2017, Vakul Garg wrote:
I am using frdm-kw41z (running hci_blackbox firmware from nxp) stacked over frdm-k64f running zephyr sample IPSP.
In this config, frdm-kw41z acts as bluetooth controller and frdm-k64f acts bluetooth host.

On the peer end, a linux machine is attached with another frdm-kw41z with same hci_blackbox firmware as above (but with different BD address).

On, running 'hcitool lescan' on linux machine, it can detect the peer IPSP node.
However, running 'hcitool lecc <ipsp node bd address>' causes following error prints on zephyr console.

net> [bt] [ERR] hci_acl: Unable to find conn for handle 32
[bt] [ERR] le_data_len_change: Unable to lookup conn for handle 32
net> [bt] [ERR] hci_num_completed_packets: No connection for handle 32

My colleague (Maureen - thanks !!) bisected the git and found that following commit is to blame.
Indeed, removing it solves the issue.

--------------------------------------------------------------------------------------
commit 56f79f817e679857e385a14f9a7e9b951dbc626e
Author: Johan Hedberg <johan.hedberg@intel.com<mailto:johan.hedberg@intel.com>>
Date: Thu Oct 5 09:43:56 2017 +0300

Bluetooth: Add support for Link Layer Privacy
--------------------------------------------------------------------------------------

Can someone please advise me if I am missing some step or is it a bug that needs to be logged?
The same issue causes problem with other Bluetooth examples such peripheral_hr etc.
Have you verified that the handle value 32 is valid, i.e. the controller
gave that in a prior LE Connection Complete event? It would help
investigate the issue if you could get the entire log and also the HCI
log of what's happening. It's not clear to me how the LL Privacy patch
could influence this.

Johan


Help needed to setup 6loble using IPSP sample

Vakul Garg <vakul.garg@...>
 

Hi

 

I am using frdm-kw41z (running hci_blackbox firmware from nxp) stacked over frdm-k64f running zephyr sample IPSP.

In this config, frdm-kw41z acts as bluetooth controller and frdm-k64f acts bluetooth host.

 

On the peer end, a linux machine is attached with another frdm-kw41z with same hci_blackbox firmware as above (but with different BD address).

 

On, running 'hcitool lescan' on linux machine, it can detect the peer IPSP node.

However, running 'hcitool lecc <ipsp node bd address>' causes following error prints on zephyr console.

 

net> [bt] [ERR] hci_acl: Unable to find conn for handle 32

[bt] [ERR] le_data_len_change: Unable to lookup conn for handle 32

net> [bt] [ERR] hci_num_completed_packets: No connection for handle 32

 

My colleague (Maureen – thanks !!) bisected the git and found that following commit is to blame.

Indeed, removing it solves the issue.

 

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

commit 56f79f817e679857e385a14f9a7e9b951dbc626e

Author: Johan Hedberg <johan.hedberg@...>

Date:   Thu Oct 5 09:43:56 2017 +0300

 

    Bluetooth: Add support for Link Layer Privacy

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

 

Can someone please advise me if I am missing some step or is it a bug that needs to be logged?

The same issue causes problem with other Bluetooth examples such peripheral_hr etc.

 

Regards

 

Vakul

 


Re: IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)

Luiz Augusto von Dentz
 

Hi Priyanka,

On Mon, Nov 20, 2017 at 4:25 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi Luiz

Luiz: Does bluetoothctl or anything else works? Can you connect to the device directly with bluetoothctl> connect <bdaddr>?

Yes bluetoothctl works. I can connect <bdaddr>. Even hcitool lescan works though not always.

# hcitool dev
Devices:
hci0 00:04:9F:00:00:15

$ bluetoothctl
[NEW] Controller 00:04:9F:00:00:15 nxaXXXXX [default]
[NEW] Device 00:04:9F:00:00:15 Test IPSP node
How come your controller has the exact same address as the device you
are trying to connect?

[bluetooth]# scan on
Discovery started
[CHG] Controller 00:04:9F:00:00:15 Discovering: yes
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# connect 00:04:9F:00:00:15
Attempting to connect to 00:04:9F:00:00:15
Connection successful
[Test IPSP node]#

hcitool lecc also works.

$ sudo hcitool lecc 00:04:9F:00:00:15
Connection handle 128

and I can see [Test IPSP node]#

In fact I can connect to the device in the first attempt, but it seems the connection drops right after that.
Afterwards, if I re-attach (hciattach) the hardware board (ble controller), it works again.

hcitool lescan also works and can discover IPSP node. Though it doesn't work all the time.

$ sudo hcitool lescan
LE Scan ...
00:04:9F:00:00:15 (unknown)
00:04:9F:00:00:15 Test IPSP node
2B:D0:07:2A:CC:15 (unknown)
45:18:78:BC:DD:6D (unknown)
59:D2:17:CF:8F:31 (unknown)
71:B0:7B:59:BC:29 (unknown)

What does not work is the following and hence, no bt interface is up.

# echo "connect 00:04:9f:00:00:15 1" > /sys/kernel/debug/bluetooth/6lowpan_control
bash: echo: write error: No route to host

On the zephyr side, it doesn't give any error.

$ hciconfig -a
hci0: Type: BR/EDR Bus: UART
BD Address: 00:04:9F:00:00:15 ACL MTU: 500:20 SCO MTU: 0:0
UP RUNNING
RX bytes:5576 acl:8 sco:0 events:380 errors:0
TX bytes:2337 acl:8 sco:0 commands:263 errors:0
Features: 0x00 0x00 0x00 0x00 0x60 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: SLAVE ACCEPT
Can't read local name on hci0: Input/output error (5)

Any suggestion on how to resolve this issue? Can't figure out if this is just a networking issue / firewall issue or Kernel issue.
Are you sure the address type is correct? Is it really

Thanks
Priyanka


-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
Sent: Monday, November 20, 2017 1:56 PM
To: Priyanka Rawat <priyanka.rawat@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)

Hi Priyanka,

On Mon, Nov 20, 2017 at 1:37 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi Luiz


I tried bluetoothctl> power on
However, this did not resolve the issue. I still get
bash: echo: write error: No route to host

I am on Linux Kernel version
Kernel 4.4.0-98 ( Ubuntu 16.04)
Anything before 4.12 is probably broken...

I wonder if I should upgrade my Linux kernel version ( / change to
another Linux distribution)?

Here is my strace, it shows coreutils.mo, libc.mo missing.
If you have any suggestion based on strace.

$strace echo "connect 00:04:9f:00:00:15 1" >
/sys/kernel/debug/bluetooth/6lowpan_control

execve("/bin/echo", ["echo", "connect 00:04:9f:00:00:15 1"], [/* 31
vars
*/]) = 0
brk(NULL) = 0x942000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb0823b6000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3,
{st_mode=S_IFREG|0644, st_size=129266, ...}) = 0 mmap(NULL, 129266,
PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb082396000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0 mmap(NULL,
3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb081dc9000
mprotect(0x7fb081f89000, 2097152, PROT_NONE) = 0 mmap(0x7fb082189000,
24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x1c0000) = 0x7fb082189000 mmap(0x7fb08218f000, 14752,
PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =
0x7fb08218f000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb082395000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb082394000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb082393000
arch_prctl(ARCH_SET_FS, 0x7fb082394700) = 0 mprotect(0x7fb082189000,
16384, PROT_READ) = 0
mprotect(0x606000, 4096, PROT_READ) = 0
mprotect(0x7fb0823b8000, 4096, PROT_READ) = 0
munmap(0x7fb082396000, 129266) = 0
brk(NULL) = 0x942000
brk(0x963000) = 0x963000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2985536, ...}) = 0 mmap(NULL,
2985536, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb081af0000
close(3) = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(1, "connect
00:04:9f:00:00:15 1\n", 28) = -1 EHOSTUNREACH (No route to
host)
close(1) = 0
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0 read(1, "#
Locale name alias data base.\n#"..., 4096) = 2995
read(1, "", 4096) = 0
close(1) = 0
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo",
O_RDONLY) = 1 fstat(1, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 1, 0) = 0x7fb0823b5000
close(1) = 0
write(2, "echo: ", 6echo: ) = 6
write(2, "write error", 11write error) = 11
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
write(2, ": No route to host", 18: No route to host) = 18
write(2, "\n", 1
) = 1
exit_group(1) = ?
+++ exited with 1 +++

Thanks
Priyanka

________________________________
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: Wednesday, November 15, 2017 1:03 PM
To: Priyanka Rawat
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP sample with KW41Z-BLE controller
gives
error: No route to host (on Linux kernel 4.4.0-98)

Hi Priyanka,

On Tue, Nov 14, 2017 at 2:47 PM, Priyanka Rawat
<priyanka.rawat@nxp.com>
wrote:
Hello


I test KW41Z-BLE controller with Zepyhr sample IPSP running in QEMU
on Linux Kernel 4.4.0-98


I load 6lowpan module and enable bluetooth_6lowpan module


# modprobe bluetooth_6lowpan
# modprobe 6lowpan

# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable


However, while connecting the device it gives error "no route to host"


# echo "connect 00:60:37:00:00:16 1" >
/sys/kernel/debug/bluetooth/6lowpan_control
bash: echo: write error: No route to host
I guess your adapter is not powered, try bluetoothctl> power on

Any idea what is missing here?


$ sudo hcitool -i hci1 lecc 00:60:37:00:00:16 Connection handle 32

Whereas this works fine when I test zephyr IPSP sample (BLE host)
with virtual BLE controller connected to QEMU serial line.


ifconfig shows bt0 up after connecting the virtual device


# echo "connect 00:aa:01:00:00:23 1" >
/sys/kernel/debug/bluetooth/6lowpan_control


# cat /sys/kernel/debug/bluetooth/6lowpan_enable
1

# cat /sys/kernel/debug/bluetooth/6lowpan_control
00:aa:01:00:00:23 (type 1)
Note, this is all being deprecated by:

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.spinics.net%2Flists%2Flinux-bluetooth%2Fmsg72592.html&data=02%7C01%7C
priyanka.rawat%40nxp.com%7Cc6284a89d516418ff50808d52c20e7d2%7C686ea1d3
bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636463442197027844&sdata=4jvlLU5JX%
2Fwon6epshV2B3EbkFTXMtLac4qzfU6abCA%3D&reserved=0

--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz


Re: IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)

Priyanka
 

Hi Luiz

Luiz: Does bluetoothctl or anything else works? Can you connect to the device directly with bluetoothctl> connect <bdaddr>?

Yes bluetoothctl works. I can connect <bdaddr>. Even hcitool lescan works though not always.

# hcitool dev
Devices:
hci0 00:04:9F:00:00:15

$ bluetoothctl
[NEW] Controller 00:04:9F:00:00:15 nxaXXXXX [default]
[NEW] Device 00:04:9F:00:00:15 Test IPSP node
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:04:9F:00:00:15 Discovering: yes
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# connect 00:04:9F:00:00:15
Attempting to connect to 00:04:9F:00:00:15
Connection successful
[Test IPSP node]#

hcitool lecc also works.

$ sudo hcitool lecc 00:04:9F:00:00:15
Connection handle 128

and I can see [Test IPSP node]#

In fact I can connect to the device in the first attempt, but it seems the connection drops right after that.
Afterwards, if I re-attach (hciattach) the hardware board (ble controller), it works again.

hcitool lescan also works and can discover IPSP node. Though it doesn't work all the time.

$ sudo hcitool lescan
LE Scan ...
00:04:9F:00:00:15 (unknown)
00:04:9F:00:00:15 Test IPSP node
2B:D0:07:2A:CC:15 (unknown)
45:18:78:BC:DD:6D (unknown)
59:D2:17:CF:8F:31 (unknown)
71:B0:7B:59:BC:29 (unknown)

What does not work is the following and hence, no bt interface is up.

# echo "connect 00:04:9f:00:00:15 1" > /sys/kernel/debug/bluetooth/6lowpan_control
bash: echo: write error: No route to host

On the zephyr side, it doesn't give any error.

$ hciconfig -a
hci0: Type: BR/EDR Bus: UART
BD Address: 00:04:9F:00:00:15 ACL MTU: 500:20 SCO MTU: 0:0
UP RUNNING
RX bytes:5576 acl:8 sco:0 events:380 errors:0
TX bytes:2337 acl:8 sco:0 commands:263 errors:0
Features: 0x00 0x00 0x00 0x00 0x60 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: SLAVE ACCEPT
Can't read local name on hci0: Input/output error (5)

Any suggestion on how to resolve this issue? Can't figure out if this is just a networking issue / firewall issue or Kernel issue.

Thanks
Priyanka

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
Sent: Monday, November 20, 2017 1:56 PM
To: Priyanka Rawat <priyanka.rawat@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)

Hi Priyanka,

On Mon, Nov 20, 2017 at 1:37 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi Luiz


I tried bluetoothctl> power on
However, this did not resolve the issue. I still get
bash: echo: write error: No route to host

I am on Linux Kernel version
Kernel 4.4.0-98 ( Ubuntu 16.04)
Anything before 4.12 is probably broken...

I wonder if I should upgrade my Linux kernel version ( / change to
another Linux distribution)?

Here is my strace, it shows coreutils.mo, libc.mo missing.
If you have any suggestion based on strace.

$strace echo "connect 00:04:9f:00:00:15 1" >
/sys/kernel/debug/bluetooth/6lowpan_control

execve("/bin/echo", ["echo", "connect 00:04:9f:00:00:15 1"], [/* 31
vars
*/]) = 0
brk(NULL) = 0x942000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb0823b6000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3,
{st_mode=S_IFREG|0644, st_size=129266, ...}) = 0 mmap(NULL, 129266,
PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb082396000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0 mmap(NULL,
3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb081dc9000
mprotect(0x7fb081f89000, 2097152, PROT_NONE) = 0 mmap(0x7fb082189000,
24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x1c0000) = 0x7fb082189000 mmap(0x7fb08218f000, 14752,
PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =
0x7fb08218f000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb082395000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb082394000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
0x7fb082393000
arch_prctl(ARCH_SET_FS, 0x7fb082394700) = 0 mprotect(0x7fb082189000,
16384, PROT_READ) = 0
mprotect(0x606000, 4096, PROT_READ) = 0
mprotect(0x7fb0823b8000, 4096, PROT_READ) = 0
munmap(0x7fb082396000, 129266) = 0
brk(NULL) = 0x942000
brk(0x963000) = 0x963000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2985536, ...}) = 0 mmap(NULL,
2985536, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb081af0000
close(3) = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(1, "connect
00:04:9f:00:00:15 1\n", 28) = -1 EHOSTUNREACH (No route to
host)
close(1) = 0
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0 read(1, "#
Locale name alias data base.\n#"..., 4096) = 2995
read(1, "", 4096) = 0
close(1) = 0
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo",
O_RDONLY) = 1 fstat(1, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 1, 0) = 0x7fb0823b5000
close(1) = 0
write(2, "echo: ", 6echo: ) = 6
write(2, "write error", 11write error) = 11
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
write(2, ": No route to host", 18: No route to host) = 18
write(2, "\n", 1
) = 1
exit_group(1) = ?
+++ exited with 1 +++

Thanks
Priyanka

________________________________
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: Wednesday, November 15, 2017 1:03 PM
To: Priyanka Rawat
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP sample with KW41Z-BLE controller
gives
error: No route to host (on Linux kernel 4.4.0-98)

Hi Priyanka,

On Tue, Nov 14, 2017 at 2:47 PM, Priyanka Rawat
<priyanka.rawat@nxp.com>
wrote:
Hello


I test KW41Z-BLE controller with Zepyhr sample IPSP running in QEMU
on Linux Kernel 4.4.0-98


I load 6lowpan module and enable bluetooth_6lowpan module


# modprobe bluetooth_6lowpan
# modprobe 6lowpan

# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable


However, while connecting the device it gives error "no route to host"


# echo "connect 00:60:37:00:00:16 1" >
/sys/kernel/debug/bluetooth/6lowpan_control
bash: echo: write error: No route to host
I guess your adapter is not powered, try bluetoothctl> power on

Any idea what is missing here?


$ sudo hcitool -i hci1 lecc 00:60:37:00:00:16 Connection handle 32

Whereas this works fine when I test zephyr IPSP sample (BLE host)
with virtual BLE controller connected to QEMU serial line.


ifconfig shows bt0 up after connecting the virtual device


# echo "connect 00:aa:01:00:00:23 1" >
/sys/kernel/debug/bluetooth/6lowpan_control


# cat /sys/kernel/debug/bluetooth/6lowpan_enable
1

# cat /sys/kernel/debug/bluetooth/6lowpan_control
00:aa:01:00:00:23 (type 1)
Note, this is all being deprecated by:

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.spinics.net%2Flists%2Flinux-bluetooth%2Fmsg72592.html&data=02%7C01%7C
priyanka.rawat%40nxp.com%7Cc6284a89d516418ff50808d52c20e7d2%7C686ea1d3
bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636463442197027844&sdata=4jvlLU5JX%
2Fwon6epshV2B3EbkFTXMtLac4qzfU6abCA%3D&reserved=0

--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz


Re: How & what to save provisioning configuration set by meshctl utility into flash memory of NRF52840-PDK ??

Johan Hedberg
 

Hi Vikrant,

On Mon, Nov 20, 2017, Vikrant More wrote:
Now I able able to access, first byte send by *"onoff"* command after
editing get_onoff_set( ) function as follow;

static void gen_onoff_set(struct bt_mesh_model *model,
struct bt_mesh_msg_ctx *ctx,
struct net_buf_simple *buf)
{

unsigned char tmp = net_buf_simple_pull_u8(buf);

NRF_P0->OUTSET |= 0x0001E000;

switch (tmp)
{
case 0: NRF_P0->OUT &= ~(1<<13); break;
case 1: NRF_P0->OUT &= ~(1<<14); break;
}
}
Good to see that you're making progress with this. Note that you'll also
need to send an OnOff Status response when receiving this message, as
section 3.3.1.2.2 in the Mesh Model Specification states:

"If the received message is a Generic OnOff Set message, the Generic
OnOff Server shall respond with a Generic OnOff Status message"

Now I want to save configuration set by meshctl utilitty into flash
memory of nRF52840-PDK board.

Plus I don't know what to save from that configuration.

Does anyone have knowledge about it ?
This is next on my to-do list for the mesh implementation. For now it's
left up to the application to store and restore the information it
wants. Most of the network state you'll be able to grab from the mesh
structs that the app defines but it's possible that for some you need to
hack the stack code itself.

Note that since we're now starting to have a Configuration Client Model
implementation as well, it opens another possibility for loading back
the values to the stack. I'm not sure if it's worth it, considering that
it involves encrypting & decrypting messages just to set some local
variables, however the benefit is reduced code duplication.

Johan


Re: IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)

Luiz Augusto von Dentz
 

Hi Priyanka,

On Mon, Nov 20, 2017 at 1:37 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi Luiz


I tried bluetoothctl> power on
However, this did not resolve the issue. I still get
bash: echo: write error: No route to host
Does bluetoothctl or anything else works? Can you connect to the
device directly with bluetoothctl> connect <bdaddr>?

I am on Linux Kernel version
Kernel 4.4.0-98 ( Ubuntu 16.04)
Anything before 4.12 is probably broken...

I wonder if I should upgrade my Linux kernel version ( / change to another
Linux distribution)?

Here is my strace, it shows coreutils.mo, libc.mo missing.
If you have any suggestion based on strace.

$strace echo "connect 00:04:9f:00:00:15 1" >
/sys/kernel/debug/bluetooth/6lowpan_control

execve("/bin/echo", ["echo", "connect 00:04:9f:00:00:15 1"], [/* 31 vars
*/]) = 0
brk(NULL) = 0x942000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb0823b6000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=129266, ...}) = 0
mmap(NULL, 129266, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb082396000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fb081dc9000
mprotect(0x7fb081f89000, 2097152, PROT_NONE) = 0
mmap(0x7fb082189000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7fb082189000
mmap(0x7fb08218f000, 14752, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb08218f000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb082395000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb082394000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fb082393000
arch_prctl(ARCH_SET_FS, 0x7fb082394700) = 0
mprotect(0x7fb082189000, 16384, PROT_READ) = 0
mprotect(0x606000, 4096, PROT_READ) = 0
mprotect(0x7fb0823b8000, 4096, PROT_READ) = 0
munmap(0x7fb082396000, 129266) = 0
brk(NULL) = 0x942000
brk(0x963000) = 0x963000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2985536, ...}) = 0
mmap(NULL, 2985536, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb081af0000
close(3) = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(1, "connect 00:04:9f:00:00:15 1\n", 28) = -1 EHOSTUNREACH (No route to
host)
close(1) = 0
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(1, "# Locale name alias data base.\n#"..., 4096) = 2995
read(1, "", 4096) = 0
close(1) = 0
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 1, 0) = 0x7fb0823b5000
close(1) = 0
write(2, "echo: ", 6echo: ) = 6
write(2, "write error", 11write error) = 11
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
write(2, ": No route to host", 18: No route to host) = 18
write(2, "\n", 1
) = 1
exit_group(1) = ?
+++ exited with 1 +++

Thanks
Priyanka

________________________________
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: Wednesday, November 15, 2017 1:03 PM
To: Priyanka Rawat
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP sample with KW41Z-BLE controller gives
error: No route to host (on Linux kernel 4.4.0-98)

Hi Priyanka,

On Tue, Nov 14, 2017 at 2:47 PM, Priyanka Rawat <priyanka.rawat@nxp.com>
wrote:
Hello


I test KW41Z-BLE controller with Zepyhr sample IPSP running in QEMU on
Linux
Kernel 4.4.0-98


I load 6lowpan module and enable bluetooth_6lowpan module


# modprobe bluetooth_6lowpan
# modprobe 6lowpan

# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable


However, while connecting the device it gives error "no route to host"


# echo "connect 00:60:37:00:00:16 1" >
/sys/kernel/debug/bluetooth/6lowpan_control
bash: echo: write error: No route to host
I guess your adapter is not powered, try bluetoothctl> power on

Any idea what is missing here?


$ sudo hcitool -i hci1 lecc 00:60:37:00:00:16
Connection handle 32

Whereas this works fine when I test zephyr IPSP sample (BLE host) with
virtual BLE controller connected to QEMU serial line.


ifconfig shows bt0 up after connecting the virtual device


# echo "connect 00:aa:01:00:00:23 1" >
/sys/kernel/debug/bluetooth/6lowpan_control


# cat /sys/kernel/debug/bluetooth/6lowpan_enable
1

# cat /sys/kernel/debug/bluetooth/6lowpan_control
00:aa:01:00:00:23 (type 1)
Note, this is all being deprecated by:

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-bluetooth%2Fmsg72592.html&data=02%7C01%7Cpriyanka.rawat%40nxp.com%7Cc6284a89d516418ff50808d52c20e7d2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636463442197027844&sdata=4jvlLU5JX%2Fwon6epshV2B3EbkFTXMtLac4qzfU6abCA%3D&reserved=0

--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz


Re: IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)

Priyanka
 

Hi Luiz


I tried bluetoothctl> power on
However, this did not resolve the issue. I still get
> bash: echo: write error: No route to host

I am on Linux Kernel version
> Kernel 4.4.0-98
( Ubuntu 16.04)

I wonder if I should upgrade my Linux kernel version ( / change to another Linux distribution)?

Here is my strace, it shows coreutils.mo, libc.mo missing.
If you have any suggestion based on strace.

$strace echo "connect 00:04:9f:00:00:15 1" > /sys/kernel/debug/bluetooth/6lowpan_control

execve("/bin/echo", ["echo", "connect 00:04:9f:00:00:15 1"], [/* 31 vars */]) = 0
brk(NULL)                               = 0x942000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb0823b6000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=129266, ...}) = 0
mmap(NULL, 129266, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb082396000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb081dc9000
mprotect(0x7fb081f89000, 2097152, PROT_NONE) = 0
mmap(0x7fb082189000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7fb082189000
mmap(0x7fb08218f000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb08218f000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb082395000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb082394000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb082393000
arch_prctl(ARCH_SET_FS, 0x7fb082394700) = 0
mprotect(0x7fb082189000, 16384, PROT_READ) = 0
mprotect(0x606000, 4096, PROT_READ)     = 0
mprotect(0x7fb0823b8000, 4096, PROT_READ) = 0
munmap(0x7fb082396000, 129266)          = 0
brk(NULL)                               = 0x942000
brk(0x963000)                           = 0x963000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2985536, ...}) = 0
mmap(NULL, 2985536, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb081af0000
close(3)                                = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(1, "connect 00:04:9f:00:00:15 1\n", 28) = -1 EHOSTUNREACH (No route to host)
close(1)                                = 0
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(1, "# Locale name alias data base.\n#"..., 4096) = 2995
read(1, "", 4096)                       = 0
close(1)                                = 0
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 1
fstat(1, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 1, 0) = 0x7fb0823b5000
close(1)                                = 0
write(2, "echo: ", 6echo: )                   = 6
write(2, "write error", 11write error)             = 11
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, ": No route to host", 18: No route to host)      = 18
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?
+++ exited with 1 +++

Thanks
Priyanka


From: Luiz Augusto von Dentz <luiz.dentz@...>
Sent: Wednesday, November 15, 2017 1:03 PM
To: Priyanka Rawat
Cc: zephyr-users@...
Subject: Re: [Zephyr-users] IPSP sample with KW41Z-BLE controller gives error: No route to host (on Linux kernel 4.4.0-98)
 
Hi Priyanka,

On Tue, Nov 14, 2017 at 2:47 PM, Priyanka Rawat <priyanka.rawat@...> wrote:
> Hello
>
>
> I test KW41Z-BLE controller with Zepyhr sample IPSP running in QEMU on Linux
> Kernel 4.4.0-98
>
>
> I load 6lowpan module and enable bluetooth_6lowpan module
>
>
> # modprobe bluetooth_6lowpan
> # modprobe 6lowpan
>
> # echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
>
>
> However, while connecting the device it gives error "no route to host"
>
>
> # echo "connect 00:60:37:00:00:16 1" >
> /sys/kernel/debug/bluetooth/6lowpan_control
> bash: echo: write error: No route to host

I guess your adapter is not powered, try bluetoothctl> power on

> Any idea what is missing here?
>
>
> $ sudo hcitool -i hci1 lecc 00:60:37:00:00:16
> Connection handle 32
>
> Whereas this works fine when I test zephyr IPSP sample (BLE host) with
> virtual BLE controller connected to QEMU serial line.
>
>
> ifconfig shows bt0 up after connecting the virtual device
>
>
> # echo "connect 00:aa:01:00:00:23 1" >
> /sys/kernel/debug/bluetooth/6lowpan_control
>
>
> # cat /sys/kernel/debug/bluetooth/6lowpan_enable
> 1
>
> # cat /sys/kernel/debug/bluetooth/6lowpan_control
> 00:aa:01:00:00:23 (type 1)

Note, this is all being deprecated by:

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-bluetooth%2Fmsg72592.html&data=02%7C01%7Cpriyanka.rawat%40nxp.com%7Cc6284a89d516418ff50808d52c20e7d2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636463442197027844&sdata=4jvlLU5JX%2Fwon6epshV2B3EbkFTXMtLac4qzfU6abCA%3D&reserved=0

--
Luiz Augusto von Dentz


How & what to save provisioning configuration set by meshctl utility into flash memory of NRF52840-PDK ??

Vikrant More <vikrant8051@...>
 

Now I able able to access, first byte send by "onoff" command after editing get_onoff_set( ) function as follow;

static void gen_onoff_set(struct bt_mesh_model *model,
              struct bt_mesh_msg_ctx *ctx,
              struct net_buf_simple *buf)
{    

        unsigned char tmp = net_buf_simple_pull_u8(buf);
   
        NRF_P0->OUTSET |= 0x0001E000;

        switch (tmp)
        {
           case 0:     NRF_P0->OUT &= ~(1<<13);  break;
           case 1:     NRF_P0->OUT &= ~(1<<14);  break;   
        }
}

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

Am also able to connect mesh n/w using "connect 0000" command.

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

Now I want to save configuration set by meshctl utilitty into flash memory of nRF52840-PDK board.

Plus I don't know what to save from that configuration.
 
Does anyone have knowledge about it ?

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


Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Kinder, David B <david.b.kinder@...>
 

Hmm... indeed something is amiss with generation of the mesh API documentation.
I'm heading out for Thanksgiving vacation, so for now, indeed the header files should be consulted. I'll submit a github issue and look into this more when I return, unless someone else wants to look into this before then.

-- david

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@intel.com]
Sent: Thursday, November 16, 2017 11:43 PM
To: Kinder, David B <david.b.kinder@intel.com>
Cc: Vikrant More <vikrant8051@gmail.com>; zephyr-
users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation
on nRF52840-PDK boards

Hi David,

On Fri, Nov 17, 2017, Kinder, David B wrote:
The documents from the master branch (including the doxygen API
material) are published nightly to
docs.zephyrproject.org<http://docs.zephyrproject.org>
Thanks, I suppose the right place should then be:

http://docs.zephyrproject.org/api/bluetooth.html#mesh-profile

However, that seems to be broken/incomplete at the moment, since it only
lists the doxygen group bt_mesh but doesn't provide any links to its
subgroups (there are many of them). If I tracked this down right the page
gets generated from doc/api/bluetooth.rst, so that likely needs fixing.
Meanwhile, it seems the best source for Mesh documentation right now is to
look at the header files directly.

Johan


Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Johan Hedberg
 

Hi David,

On Fri, Nov 17, 2017, Kinder, David B wrote:
The documents from the master branch (including the doxygen API
material) are published nightly to
docs.zephyrproject.org<http://docs.zephyrproject.org>
Thanks, I suppose the right place should then be:

http://docs.zephyrproject.org/api/bluetooth.html#mesh-profile

However, that seems to be broken/incomplete at the moment, since it only
lists the doxygen group bt_mesh but doesn't provide any links to its
subgroups (there are many of them). If I tracked this down right the
page gets generated from doc/api/bluetooth.rst, so that likely needs
fixing. Meanwhile, it seems the best source for Mesh documentation right
now is to look at the header files directly.

Johan


Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Kinder, David B <david.b.kinder@...>
 

The documents from the master branch (including the doxygen API material) are published nightly to docs.zephyrproject.org

-- david kinder

On Nov 16, 2017, at 10:42 PM, Johan Hedberg <johan.hedberg@...> wrote:

Hi Vikrant,

On Fri, Nov 17, 2017, Vikrant More wrote:
Could you please share in details documentation for Bluetooth Mesh
implementation for Zephyr ?

The API is documented with the usual doxygen syntax. I'm not sure how
frequently documentation in the master branch gets generated onto the
website, so it might be better for you to generate the documentation
either yourself, or perhaps simpler, look at the header files directly.
They can be found under include/bluetooth/mesh/ in the master branch.

Another good reference is how the mesh sample applications use the API,
so you could look e.g. at samples/bluetooth/src/main.c. Yet another
fairly good reference is the implementation of the foundation models,
which you can find in subsys/bluetooth/host/mesh/cfg_srv.c and
subsys/bluetooth/host/mesh/health_srv.c (note that these are only valid
for the latest master branch since the files were recently renamed).

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


Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Johan Hedberg
 

Hi Vikrant,

On Fri, Nov 17, 2017, Vikrant More wrote:
Could you please share in details documentation for Bluetooth Mesh
implementation for Zephyr ?
The API is documented with the usual doxygen syntax. I'm not sure how
frequently documentation in the master branch gets generated onto the
website, so it might be better for you to generate the documentation
either yourself, or perhaps simpler, look at the header files directly.
They can be found under include/bluetooth/mesh/ in the master branch.

Another good reference is how the mesh sample applications use the API,
so you could look e.g. at samples/bluetooth/src/main.c. Yet another
fairly good reference is the implementation of the foundation models,
which you can find in subsys/bluetooth/host/mesh/cfg_srv.c and
subsys/bluetooth/host/mesh/health_srv.c (note that these are only valid
for the latest master branch since the files were recently renamed).

Johan


Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

Could you please share in details documentation for Bluetooth Mesh implementation for Zephyr ?

On Fri, Nov 17, 2017 at 11:43 AM, Vikrant More <vikrant8051@...> wrote:
patch are giving me error. 

So please share original files.

what is original file for bluez-mesh.patch ?


On Fri, Nov 17, 2017 at 11:28 AM, Vikrant More <vikrant8051@...> wrote:
I simply add nrf52840.h & nrf_delay.h from nrf52_SDK into --> zephyr/boards/arm/nrf52840_pca10056.

And include these headder file in main.c ( Zephyr Mesh Example)

After that I add following line for testing of integration of newly added files with Zephyr project.



void main(void)
{
int err;
        
        NRF_P0->DIR |= 0x0001E000;
        NRF_P0->OUTSET |= 0x0001E000;
        
        while(1)
        {
           printk("Initializing...\n");

           NRF_P0->OUT ^= 0x0001E000;
        
          nrf_delay_ms(100);

        } 

/* Initialize the Bluetooth Subsystem */
err = bt_enable(bt_ready);
if (err) {
printk("Bluetooth init failed (err %d)\n", err);
}
}


After executing this on PDK board, I get result as expected .....All four LEDs are blinking continuously.



Next,

I removed above mentioned while loop & edit 

static void gen_onoff_get(struct bt_mesh_model *model,
  struct bt_mesh_msg_ctx *ctx,
  struct net_buf_simple *buf)
{
    NRF_P0->OUT |= 0x0001E000;
}

static void gen_onoff_set(struct bt_mesh_model *model,
  struct bt_mesh_msg_ctx *ctx,
  struct net_buf_simple *buf)
{
    NRF_P0->OUT &= 0xFFFE1FFF;
}


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

After giving onoff 1 / get on [on/off: Target=0111]# terminal I get following error -->

Failed to write


After trying same command again it does not reply anything. But LEDs status is also not changes on the Board.

On Thu, Nov 16, 2017 at 7:32 PM, Steve Brown <sbrown@...> wrote:
Here is the code I've been working with.

There is a patch to sample/bluetooth/mesh/main.c and another one to
bluez's mesh stuff.

The first one adds the led code. Some is commented out for working on
another board. I had all 4 leds working at 0100, 0101, 0102 & 0103. Per
the mesh specs, 0100 is the primary element and is the only one with a
config and health server. It also adds an onoff client for the button.
I only hooked up one button. If you want to experiment with group
addresses, you need to configure the button client (element 0100 &
model 1001) to publish to a group address, like c000 and set one or
more buttons to subscribe to c000. That way the button can control more
than one led. Also, the provisioning UUID is set to the MAC address of
the board instead of dddd00...000 so you don't have to power the boards
up one at a time.

You can't use meshctl to send onoff to group addresses. That isn't
implemented yet in the bluez mesh stack.

The bluez's patch adds some informational diagnostics, fixes a bug in
ascii oob input and adds heartbeat and subscribe commands.

I'm certain this is all very buggy, but it's been pretty educational
getting this far.

Steve


On Thu, 2017-11-16 at 19:04 +0530, Vikrant More wrote:
> [meshctl]# configure 0109
> [config: Target = 0109]# add-appkey 1
> [config: Target = 0109]# bind 0 1 1000
> [config: Target = 0109]# back
> [meshctl]# onoff 0109
> [on/off: Target = 0109] onoff 1     // nothing changed on PDK serial
> terminal nor changed LED status
> [on/off: Target = 0109] onoff 0     // nothing changed on PDK serial
> terminal nor changed LED status
>
> I last mail you mentioned that, to change LED status we have to write
> code which will execute after giving onoff 1/0 command.
> So could you please help me it that ?
>
> I know this code to Turn LED1 ON:
> NRF_P0 ->OUT &= ~(1<<13);
>
> & for off -->  NRF_P0 ->OUT |= (1<<13);
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 16, 2017 at 6:42 PM, Steve Brown <sbrown@...>
> wrote:
> > Looks like you are making progress.
> >
> > I'd recommend that you do a "git checkout mesh/*.json" when you
> > start
> > each session. Otherwise, the node/element data accumulates and it's
> > hard to keep track of which node is which. This initializes the
> > first
> > element to 0100.
> >
> > Before you can use the onoff server, you have to issue the
> > following
> > configure commands:
> >
> > add-appkey 1   # that's the appkey that meshctl uses for the onoff
> > app
> > bind 0 1 1000  # this binds that appkey to the onoff server
> >
> > Now the onoff server should be able to accept meshctl onnoff
> > commands.
> >
> > Steve
> >
> > On Thu, 2017-11-16 at 18:26 +0530, Vikrant More wrote:
> > > Thanks !!
> > >
> > > After following your idea,
> > >
> > > On [nRF52840 termianl]-->  provisined ......
> > >                                              Failed to advertise
> > > using Node ID (err -5)
> > >
> > > & after this PDK board stop advertising itself as "Zephyr"
> > >
> > >
> > > If I hit command as "provision dddd0000000000000000000000000000"
> > > then it give as o/p as --> Already provisioned with unicast 0106
> > >
> > > So unicast address is 0106
> > >
> > > Then I run --> configure 0106
> > > [config: Target = 0077]# help
> > >
> > >  Client Configuration Menu
> > > Available commands:
> > >   target <unicast>                          Set target node to
> > > configure
> > >   get-composition [<page_num>]              Get Composition Data
> > >   add-netkey <net_idx>                      Add network key
> > >   del-netkey <net_idx>                      Delete network key
> > >   add-appkey <app_idx>                      Add application key
> > >   del-appkey <app_idx>                      Delete application
> > key
> > >   bind <ele_idx> <app_idx> <mod_id> [cid]   Bind app key to a
> > model
> > >   set-ttl <ttl>                             Set default TTL
> > >   get-ttl                                   Get default TTL
> > >   set-pub <ele_addr> <pub_addr> <app_idx> <period (step|res)>
> > <model>
> > > Set publication
> > >   back                                      Back to main menu
> > >   help                                      Config Commands
> > >
> > >
> > > If I run --> onff 0106       it gives
> > >
> > > [on/off: Target = 0106]# help
> > > Client Configuration Menu
> > > Available commands:
> > >   target <unicast>                          Set node to configure
> > >   get                                       Get ON/OFF status
> > >   onoff <0/1>                               Send "SET ON/OFF"
> > command
> > >   back                                      Back to main menu
> > >   help                                      Config Commands
> > > [on/off: Target = 0106]#
> > >
> > > If I run --> [on/off: Target = 0106]#  onoff 0          it gives
> > > Failed to write
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then we test #
> > >
> > > On Thu, Nov 16, 2017 at 4:53 PM, Steve Brown <sbrown@...
> > >
> > > wrote:
> > > > In the 52840 terminal output, you will see something like:
> > > >
> > > > OOB Number: 6021
> > > >
> > > > That's the number to input to meshctl.
> > > >
> > > > Steve
> > > >
> > > > On Thu, 2017-11-16 at 16:11 +0530, Vikrant More wrote:
> > > > > On [meshctl] --> [mesh] Enter Numeric key:
> > > > > Here I input 1234
> > > > >
> > > > > On [nRF52840 termianl]--> Invalid Confirmation Value
> > > > >
> > > > >
> > > > >
> > > > > -----------------------------------------------------------
> > ----
> > > > ----
> > > > > ------------------------------------------
> > > > >
> > > > > On Thu, Nov 16, 2017 at 2:14 PM, Steve Brown <sbrown@cortland
> > .com
> > > > >
> > > > > wrote:
> > > > > > In looking at the output again, It doesn't look like
> > > > > > provisioningcompleted.
> > > > > >
> > > > > > The out-of-band code is output on the 52840's serial port
> > and
> > > > > > forwarded
> > > > > > to probably /dev/ttyACM0. That's the code you need to
> > enter.
> > > > > >
> > > > > > Steve
> > > > > >
> > > > > > On Thu, 2017-11-16 at 10:45 +0530, Vikrant More wrote:
> > > > > > > It is working now !!
> > > > > > > I run hcitool lescan on another terminal & { discover-
> > > > > > unprovisioned
> > > > > > > on , provision dddd0000000000000000000000000000 } on
> > messhctl
> > > > > > > terminal.
> > > > > > >
> > > > > > > Output -->
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -----------------------------
> > > > > > >
> > > > > > > [meshctl]# discover-unprovisioned on
> > > > > > > set_scan_filter_uuids 00001827-0000-1000-8000-
> > 00805f9b34fb
> > > > > > > SetDiscoveryFilter success
> > > > > > > Discovery started
> > > > > > > Adapter property changed
> > > > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
> > > > > > >               Mesh Provisioning Service (00001827-0000-
> > 1000-
> > > > 8000-
> > > > > > > 00805f9b34fb)
> > > > > > >                       Device UUID:
> > > > > > dddd0000000000000000000000000000
> > > > > > >                       OOB: 0000
> > > > > > > [NEW] Device EA:E8:05:9B:16:1D Zephyr
> > > > > > > [meshctl]# provision dddd0000000000000000000000000000
> > > > > > > Trying to connect Device EA:E8:05:9B:16:1D Zephyr
> > > > > > > Adapter property changed
> > > > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: no
> > > > > > > [Zephyr]# Connection successful
> > > > > > > [Zephyr]# Service added
> > > > > > > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service0006
> > > > > > > Service added
> > > > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a
> > > > > > > Char added
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b:
> > > > > > > Char added
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d:
> > > > > > > Services resolved yes
> > > > > > > Found matching char: path
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b,
> > > > uuid
> > > > > > > 00002adb-0000-1000-8000-00805f9b34fb
> > > > > > > Found matching char: path
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d,
> > > > uuid
> > > > > > > 00002adc-0000-1000-8000-00805f9b34fb
> > > > > > > Start notification on
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > Notify started
> > > > > > > Notify for Mesh Provisioning Out Data started
> > > > > > > Open-Node: 0x1444640
> > > > > > > Open-Prov: 0x1446380
> > > > > > > Open-Prov: proxy 0x144a150
> > > > > > > GATT-TX:  03 00 10
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Initiated provisioning
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 01 01 00 01 00 00 04 00 08 00 00 00
> > > > > > > Got provisioning data (12 bytes)
> > > > > > >        01 01 00 01 00 00 04 00 08 00 00 00
> > > > > > > GATT-TX:  03 02 00 00 02 03 04
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > GATT-TX:  03 03 a8 09 93 50 18 6f 0d 3a cb af 39 40 28 60
> > > > > > > GATT-TX:  9b fa 15 c9
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c
> > e4
> > > > c7
> > > > > > > GATT-RX:       fe c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca
> > 74
> > > > af
> > > > > > > GATT-RX:       ed 3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12
> > 8d
> > > > 3c
> > > > > > > GATT-RX:       f3 79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7
> > 39
> > > > ab
> > > > > > > GATT-RX:       9f e3
> > > > > > > Got provisioning data (65 bytes)
> > > > > > >        03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 fe
> > > > > > >        c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af ed
> > > > > > >        3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c f3
> > > > > > >        79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 9f
> > > > > > >        e3
> > > > > > > Request decimal key (0 - 9999)
> > > > > > > [mesh] Enter Numeric key: 1234
> > > > > > > GATT-TX:  03 05 79 75 31 d9 3c ce a3 27 2c d7 1b 5d 90 f3
> > > > > > > GATT-TX:  30 27
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6
> > f5
> > > > 05
> > > > > > > GATT-RX:       d2 40
> > > > > > > Got provisioning data (17 bytes)
> > > > > > >        05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 d2
> > > > > > >        40
> > > > > > > GATT-TX:  03 06 af 78 37 46 88 64 92 8f f1 f4 9c c1 18 95
> > > > > > > GATT-TX:  a7 8d
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > [Zephyr]#
> > > > > > >
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > ---
> > > > > > >
> > > > > > > Now what to do next ??
> > > > > > > I've repeat this procedure on all three board.
> > > > > > >
> > > > > > > How to control LEDs on these board using meshctl or any
> > > > android
> > > > > > APP
> > > > > > > ??
> > > > > > >
> > > > > > > Thank You!!
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>



2381 - 2400 of 2659