Date   

Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi,

I had a chance to look at this further.

More at the bottom.


On Thu, 2018-04-26 at 15:24 +0300, Johan Hedberg wrote:
Hi,

This was already identified as a bug in meshctl by Steve, a week ago
or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr
project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of
today, you can see that my log is the same like yours, after close
the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb

Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX: 03 00 10

GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00

Got provisioning data (12 bytes)

01 04 00 01 00 00 06 00 18 00 00 00

GATT-TX: 03 02 00 00 02 04 06

GATT-TX: 03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is
basing on the commit, c33087d3366f395168d477feb631aae1785a008e on
March 29th, it works well, you can see below screenshot that BlueZ
could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 03 00 10
GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00
Got provisioning data (12 bytes)
01 04 00 01 00 00 06 00 18 00 00 00
GATT-TX: 03 02 00 00 02 04 06
GATT-TX: 03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-
00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002add-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002ade-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys,
just guessing…

Regards,
Kai



From: Vikrant More <vikrant8051@...>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <
devel@...>, "users@..." <us
ers@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh
provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh
library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did
not complete.

This is complete log,
-----------------------------------------------------------------
-----------------------------------------------------------------
-----------------------------------------------------------------
-------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...
m<mailto:vikrant8051@...>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...<mailto:kr
en@...>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make
model configuration, use meshctl "menu onoff" to control LED on and
off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last
week, it was successful, so BlueZ works well, the issue may be from
Zephyr.

Kai

It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>

Steve


Re: Going mad about I2C #i2c #stm32 #nrf51822

Yannis Damigos
 

Hi Roman,

you need to update boards pinmux.c file to add the I2C pins. You could
check olimexino_stm32 board's pinmux file for reference.

Yannis
On Mon, Apr 30, 2018 at 10:36 AM Roman Tataurov <diytronic@...> wrote:

MCU is this
https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/arch/arm/soc/st_stm32/stm32f1
Using this board
https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/stm32_min_dev

Seems it completely off i2c devices so added to board dts
&i2c1 {
status = "ok";
};
&i2c2 {
status = "ok";
};
To make it work. Together with bug fixed about DTS
https://github.com/zephyrproject-rtos/zephyr/issues/7248 I have now I2C
device created. So code is work now.
But still no activities on device pins. Checked all the pins with logick
analser and found nothing.

I suspect some GPIO setup required.


Re: Going mad about I2C #i2c #stm32 #nrf51822

Roman Tataurov
 

MCU is this https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/arch/arm/soc/st_stm32/stm32f1
Using this board https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/stm32_min_dev

Seems it completely off i2c devices so added to board dts 

&i2c1 {
        status = "ok";
};
 
&i2c2 {
        status = "ok";
};
To make it work. Together with bug fixed about DTS https://github.com/zephyrproject-rtos/zephyr/issues/7248 I have now I2C device created. So code is work now. 
But still no activities on device pins. Checked all the pins with logick analser and found nothing.

I suspect some GPIO setup required.


Re: Going mad about I2C #i2c #stm32 #nrf51822

Rodrigo Peixoto <rodrigopex@...>
 

Describe better your environment.

Which board (and no MCU) are you using? Based on the http://docs.zephyrproject.org/boards/arm/nucleo_f103rb/doc/nucleof103rb.html it seems that the i2c_1 that it might be the I2C_0 in Zephyr is on the PORTB. I have added the following line #define CONFIG_I2C_0_NAME "PORTB". For the https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/samples/drivers/i2c_fujitsu_fram example. It compiles but I don't have the board here to test.

Try this and let us know.

Best regards, Rodrigo Peixoto.


Re: Going mad about I2C #i2c #stm32 #nrf51822

Rodrigo Peixoto <rodrigopex@...>
 

Hi Roman,

I was taking a look at the list and I've found something that may help you. Go to the link https://lists.zephyrproject.org/g/users/message/371 and check the solution. I think that maybe you can try something similar to that. Remember that the hardware used in the example is a nrf52 and yours is a nrf51, but the device names for this case are the same.

The STM32F103 I don't know the dev name. You can check that directly on the source code (board.h -> https://github.com/zephyrproject-rtos/zephyr/blob/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/nucleo_f103rb/board.h). Maybe the name for the device is PORTA or PORTC it depends on the which one is the I2C port for your project.

I hope it helps.

Best regards, Rodrigo Peixoto. Ayna Tech +55 (82) 98144-8585.


Going mad about I2C #i2c #stm32 #nrf51822

Roman Tataurov
 

Hello!

Today almost whole day frustrating trying to make work I2C on Zephyr.
Tested on 2 different boards with nrf51822 and stm32f103 MCU-s and got no success.

Any options for both MCU-s different than bitbang I2C even return null for device_get_binding so I can't even initialize it. 
In case of bitbang I2C implementation device driver exists but does not work. Mean code executed, but I see nothing on MCU pins. 
Mapped to different GPIO variants, checked with logick analyzer on all the pins but nothing. It just does not work at all.

So can anobody explain right path to make it finally work.

So for STM32 (not a bitbang) used with:

CONFIG_GPIO=y
CONFIG_GPIO_STM32=y
CONFIG_GPIO_STM32_PORTA=y
CONFIG_GPIO_STM32_PORTB=y

CONFIG_I2C=y
CONFIG_I2C_INIT_PRIORITY=60
CONFIG_SYS_LOG_I2C_LEVEL=4
# CONFIG_I2C_0 is not set     <-------- tested with this as well
CONFIG_I2C_1=y 
# CONFIG_I2C_2 is not set
# CONFIG_I2C_3 is not set
# CONFIG_I2C_DW is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_SBCON is not set
CONFIG_I2C_STM32=y
CONFIG_I2C_STM32_V1=y

For nrf51 dont remember but can try again and put config here.

Any help appreciated.



Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto <rodrigopex@...>
 

Vikrant and others, I was wondering here... Is there any way of using Bluetooth mesh by using the Nordic HAL (NRFX) instead of using the Zephyr's one?

Thank you. Best regards, Rodrigo Peixoto.


Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto <rodrigopex@...>
 

Vikrant,
answering inline. 

Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. 

Ok.
 
Now I will prefer to wait till 
1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash

2) plus it should also take care of saving data like sequence no. &  Model states on SoC flash on periodic basis

This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective.

There will be roughly four section in SoC flash-

1. for MCUboot
2. for flash memory (which will acts like eeprom)
3. slot_0 (current image)
4. slot_1 ( temporary location for new image after DFU )

This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. 

So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution.

I really need that.
 
Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image.

Do you need help on that? I am a little bit confusing. 
I was willing to create the sample related to OTA and mesh. But if there is other sample as you said related to mesh, it would be a pleasure to help.

Is there any thing I can do?

Best regards,
Rodrigo Peixoto.


Re: Device Firmware Update + Zephyr + #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Rodrigo,

Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. 

Now I will prefer to wait till 
1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash

2) plus it should also take care of saving data like sequence no. &  Model states on SoC flash on periodic basis

This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective.

There will be roughly four section in SoC flash-

1. for MCUboot
2. for flash memory (which will acts like eeprom)
3. slot_0 (current image)
4. slot_1 ( temporary location for new image after DFU )

This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. 

So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution.

Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image.

Regards,
Vikrant

On Fri, Apr 27, 2018, 7:44 PM Rodrigo Peixoto <rodrigopex@...> wrote:

Hi vikrant.

I could do the integration! Now the SMP_Server sample is integrated to the mesh one. I need to play a little more with it. I have already tested the mcumgr a lot, but not too much the mesh one after the integration. I am considering the possibility of creating a sample with the integrated code.

What do you think? Necessary?

Best regards, Rodrigo Peixoto.


Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto <rodrigopex@...>
 

Hi vikrant.

I could do the integration! Now the SMP_Server sample is integrated to the mesh one. I need to play a little more with it. I have already tested the mcumgr a lot, but not too much the mesh one after the integration. I am considering the possibility of creating a sample with the integrated code.

What do you think? Necessary?

Best regards, Rodrigo Peixoto.


Re: time between two packets(advertisement)

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Swapnil,

On 25 Apr 2018, at 09:21, swapnil <swapnil2007kadam@...> wrote:

Hello,
is it possible to change the time or provide a delay between two consecutive packets sent on two different advertising channels?
No, not without changing the implementation. Changing or having such a delay means that the reserved time of BLE event should also be adjusted. And, such a delay would also reduce overall on-air radio utilisation, reducing the implementations throughput.

packet on channel 37 --> delay --> packet on channel 38 --> delay -->packet on channel 39.
(delay = time between the start of the packet on 1 channel and the start of the packet on another channel.)

as per the core specifications delay could be <= 10ms but I checked the existing delay which is less than 200us ( i could be wrong). is it possible to change the delay by changing some value in ctrl.c or somewhere else?
Under non-connectable advertising, if I remember correct, the end of packet on one channel to the start of packet on another channel is as low as 70 us in the nRF52 series implementations (lower the better!).
No, no simple change of value in ctrl.c would provide you such delay.

You are asking a very difficult feature, to reduce radio utilisation/throughout ;-). But yes, if we can “design" with radio utilisations inside these delays, such a feature is reasonable, but so far there is no such strong requirement to delay or expand an advertising event time beyond its lowest possible event length.

Thank you in advance.
regards,
Swapnil
Regards,
Vinayak


Re: NXP MCUX RTC implementation

Franco Saworski <franco.saworski@...>
 

Thanks to everyone offering help.
We finished the project and pushed a pullrequest [1] to add an NXP MCUX RTC driver to Zephyr.

Kind regards,
Franco


On Sun, 1 Apr 2018 at 12:32 Michael Hope <michaelh@...> wrote:
Hi Franco.  I don't know of any technical limitation, but from what I've seen so far the Zephyr community takes a broad but shallow approach - for example, I've been adding support for the SAMD21 used in the Arduino Zero so I've focused on the SPI, USB, Flash, and GPIO drivers that I need and skipped others like PWM or ADC.

-- Michael
On Wed, 28 Mar 2018 at 16:20 Franco Saworski <franco.saworski@...> wrote:
Hi,

we at blik are working with Zephyr on one of our hardware units, and would like to use a lowpower mechanism along with an RTC wakeup.

Unfortunately RTC implementations are sparse, with only one implementation present. Is there a technical limitation or reason for this?
As far as I understand, SoC lowpower implementations are omitted in Zephyr, because they are usually usecase specific. I can't imagine the same for RTC.

Furthermore, we are looking for someone to develop the RTC driver and ultimately upstream it, as a small paid project. Please feel free to message me, if you're interested.

Kind regards,
Franco Saworski


--

Embedded Engineer

blik GmbH
transparent real-time data

HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.
_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
--

Embedded Engineer

blik GmbH
transparent real-time data

Leonrodstraße 68 | 80636 München
HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi,

This was already identified as a bug in meshctl by Steve, a week ago or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can see that my log is the same like yours, after close the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX: 03 00 10

GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00

Got provisioning data (12 bytes)

01 04 00 01 00 00 06 00 18 00 00 00

GATT-TX: 03 02 00 00 02 04 06

GATT-TX: 03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is basing on the commit, c33087d3366f395168d477feb631aae1785a008e on March 29th, it works well, you can see below screenshot that BlueZ could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 03 00 10
GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00
Got provisioning data (12 bytes)
01 04 00 01 00 00 06 00 18 00 00 00
GATT-TX: 03 02 00 00 02 04 06
GATT-TX: 03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002add-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002ade-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys, just guessing…

Regards,
Kai



From: Vikrant More <vikrant8051@...>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...<mailto:vikrant8051@...>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...<mailto:kren@...>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr.

Kai


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Kai Ren <kren@...>
 

Hi Vikrant,

I just did two tests today, the detail is:

 

1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can see that my log is the same like yours, after close the connection, need to initial a new connection, but it’s failed.

 

[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     03 00 10 

GATT-RX:     03 01 04 00 01 00 00 06 00 18 00 00 00 

Got provisioning data (12 bytes)

       01 04 00 01 00 00 06 00 18 00 00 00 

GATT-TX:     03 02 00 00 02 04 06 

GATT-TX:     03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56 

GATT-TX:     93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be 

GATT-TX:     75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c 

GATT-TX:     3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9 

GATT-TX:     e9 60 

GATT-RX:     03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 

GATT-RX:     68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 

GATT-RX:     01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 

GATT-RX:     49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 

GATT-RX:     4c bf 

Got provisioning data (65 bytes)

       03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68 

       cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01 

       32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49 

       a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c 

       bf 

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX:     03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3 

GATT-TX:     83 c4 

GATT-RX:     03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 

GATT-RX:     90 76 

Got provisioning data (17 bytes)

       05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90 

       76 

GATT-TX:     03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18 

GATT-TX:     d8 91 

GATT-RX:     03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 

GATT-RX:     b1 ea 

Got provisioning data (17 bytes)

       06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1 

       ea 

Confirmation Validated

S-Key  37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14 

S-Nonce       d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb 

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f 

Data   18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12 

Data   00 00 00 00 00 00 05 01 13 

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00 

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca 

DataEncrypted + mic 5b 

GATT-TX:     03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 

GATT-TX:     6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 

GATT-TX:     0f ca 5b 

GATT-RX:     03 08 

Got provisioning data (1 bytes)

       08 

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]# 

 

 

2nd test, I “make clean” and “make”, this time, “onoff-app” is basing on the commit, c33087d3366f395168d477feb631aae1785a008e on March 29th, it works well, you can see below screenshot that BlueZ could get Composition Data.

 

[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x1915e08

Open-Prov: 0x19149d0

Open-Prov: proxy 0x19124d8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     03 00 10 

GATT-RX:     03 01 04 00 01 00 00 06 00 18 00 00 00 

Got provisioning data (12 bytes)

       01 04 00 01 00 00 06 00 18 00 00 00 

GATT-TX:     03 02 00 00 02 04 06 

GATT-TX:     03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4 

GATT-TX:     51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4 

GATT-TX:     0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7 

GATT-TX:     fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f 

GATT-TX:     e1 0f 

GATT-RX:     03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 

GATT-RX:     4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 

GATT-RX:     1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 

GATT-RX:     e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 

GATT-RX:     7c 49 

Got provisioning data (65 bytes)

       03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e 

       1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c 

       5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3 

       32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c 

       49 

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): RZTCNG

GATT-TX:     03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd 

GATT-TX:     fa f7 

GATT-RX:     03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 

GATT-RX:     3c a3 

Got provisioning data (17 bytes)

       05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c 

       a3 

GATT-TX:     03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27 

GATT-TX:     dd dc 

GATT-RX:     03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 

GATT-RX:     b7 9f 

Got provisioning data (17 bytes)

       06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7 

       9f 

Confirmation Validated

S-Key  2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec 

S-Nonce       69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03 

DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70 

Data   18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12 

Data   00 00 00 00 00 00 05 01 1b 

DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d 

DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71 

DataEncrypted + mic 2b 

GATT-TX:     03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 

GATT-TX:     3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 

GATT-TX:     3c 71 2b 

GATT-RX:     03 08 

Got provisioning data (1 bytes)

       08 

Provision success. Assigned Primary Unicast 011b

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

 

              Mesh Proxy Service (00001828-0000-1000-8000-00805f9b34fb)

              Identity for node 011b

Trying to connect to mesh

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002add-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002ade-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Proxy Out Data started

Trying to open mesh session

GATT-RX:     01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4 

GATT-RX:     0a 41 fa b0 af 32 0b 

iv_upd_state = IV_UPD_NORMAL

Mesh session is open

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02 

GATT-TX:     a7 77 d9 51 

GATT-TX:     00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07 

GATT-TX:     57 67 06 0c 51 02 

GATT-RX:     02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0 

GATT-RX:     78 86 79 a1 ea fd 

Proxy Whitelist filter length: 0

GATT-RX:     00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e 

GATT-RX:     4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d 

GATT-RX:     00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb 

GATT-RX:     2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9 

GATT-RX:     00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39 

GATT-RX:     97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71 

GATT-RX:     00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc 

GATT-RX:     7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30 

GATT-RX:     00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92 

GATT-RX:     ea eb dc 22 e8 61 3e d5 02 5b 3c 12 

       Composition data for node 011b {

  "cid":"05f1",

  "pid":"0000",

  "vid":"0000",

  "crpl":"000a",

  "features":{

    "relay":true,

    "proxy":true,

    "friend":false,

    "lpn":false

  },

  "elements":[

    {

      "elementIndex":0,

      "location":"0000",

      "models":[

        "0000",

        "0001",

        "0002",

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":1,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":2,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":3,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    }

  ]

}

GATT-TX:     00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65 

GATT-TX:     0b f9 13 7b fb 95 19 e4 a5 

[Zephyr-Node-011b]

 

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys, just guessing…

 

Regards,

Kai

 

 

 

From: Vikrant More <vikrant8051@...>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49)

 

HI Kai,

Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

 

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX:     03 00 10
GATT-RX:     03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
     01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX:     03 02 00 00 00 00 00
GATT-TX:     03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX:     2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX:     4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX:     31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX:     52 ea
GATT-RX:     43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX:     10 28 b4 89
GATT-RX:     83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX:     87 b9 2b a3
GATT-RX:     83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX:     b7 1a f5 1d
GATT-RX:     c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
     03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
     28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
     14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
     5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
     27
GATT-TX:     03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX:     82 90
GATT-RX:     03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX:     59 d0
Got provisioning data (17 bytes)
     05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
     d0
GATT-TX:     03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX:     a2 b6
GATT-RX:     03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX:     f1 88
Got provisioning data (17 bytes)
     06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
     88
Confirmation Validated
S-Key     bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce     1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey     24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data     18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data     00 00 00 00 00 00 05 01 00
DataEncrypted + mic     6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic     44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic     67
GATT-TX:     03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX:     37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX:     50 01 67
GATT-RX:     03 08
Got provisioning data (1 bytes)
     08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

 

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...> wrote:

Hi Kai, 

 

Yes, you are right. Thanks for sharing it. 

 

Regards,

vikrant

 

 

On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...> wrote:

Hi Vikrant8051, 

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr. 

Kai  

 


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

HI Kai,

Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX:     03 00 10
GATT-RX:     03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
     01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX:     03 02 00 00 00 00 00
GATT-TX:     03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX:     2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX:     4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX:     31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX:     52 ea
GATT-RX:     43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX:     10 28 b4 89
GATT-RX:     83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX:     87 b9 2b a3
GATT-RX:     83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX:     b7 1a f5 1d
GATT-RX:     c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
     03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
     28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
     14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
     5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
     27
GATT-TX:     03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX:     82 90
GATT-RX:     03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX:     59 d0
Got provisioning data (17 bytes)
     05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
     d0
GATT-TX:     03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX:     a2 b6
GATT-RX:     03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX:     f1 88
Got provisioning data (17 bytes)
     06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
     88
Confirmation Validated
S-Key     bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce     1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey     24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data     18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data     00 00 00 00 00 00 05 01 00
DataEncrypted + mic     6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic     44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic     67
GATT-TX:     03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX:     37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX:     50 01 67
GATT-RX:     03 08
Got provisioning data (1 bytes)
     08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...> wrote:
Hi Kai, 

Yes, you are right. Thanks for sharing it. 

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...> wrote:

Hi Vikrant8051, 

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr. 

Kai  



time between two packets(advertisement)

swapnil <swapnil2007kadam@...>
 

Hello,
is it possible to change the time or provide a delay between two consecutive packets sent on two different advertising channels?

packet on channel 37 --> delay  --> packet on channel 38 --> delay -->packet on channel 39.
(delay = time  between the start of the packet on 1 channel and the start of the packet on another channel.)

as per the core specifications delay could be <= 10ms but I checked the existing delay which is less than 200us ( i could be wrong). is it possible to change the delay by changing some value in ctrl.c or somewhere else?
Thank you in advance.
regards,
Swapnil


Re: payload 251 byte with beacon sample

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Swapnil,

Legacy advertising channels do not support 251 byte PDUs.

The configuration CONFIG_BT_CTLR_DATA_LENGTH=y, you are setting is only valid for data connections. The beacon sample is only a broadcaster hence the Kconfig warns about the feature being disabled due to connection support dependency.

If you are looking for broadcasting 251 byte PDUs, LE advertising extensions feature is not yet supported in the Zephyr upstream master repository.

Regards,
Vinayak

From: users@... [mailto:users@...] On Behalf Of swapnil
Sent: Tuesday, April 24, 2018 12:33 PM
To: users@...
Subject: [Zephyr-users] payload 251 byte with beacon sample

HELLO, 
i am new to zephyr.  and trying to send a message with 251 byte payload. how can I set the controller.? 
 
i am using following configuration:

CONFIG_BT=y

CONFIG_BT_CTLR = y

CONFIG_BT_DEBUG_LOG=y

CONFIG_BT_DEVICE_NAME="Test beacon"

CONFIG_HAS_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_UART_CONSOLE=n

CONFIG_BT_DEBUG_MONITOR=y

CONFIG_BT_DEBUG_HCI_CORE=y

CONFIG_BT_CTLR_ADV_EXT=y

CONFIG_BT_BROADCASTER=y

CONFIG_BT_DEBUG_HCI_DRIVER=y

CONFIG_BT_CTLR_DATA_LENGTH=y


CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_CTLR_TX_BUFFER_SIZE=251

CONFIG_BT_CONN = y

CONFIG_BT_LL_SW = y

BT_CTLR_DATA_LENGTH_MAX = y

CONFIG_BT_HCI = y

CONFIG_SOC_SERIES_NRF52X = y

CONFIG_BT_CTLR_ADVANCED_FEATURES = y

 

 


but it throws following warnings:

 

/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:15: warning: attempt to assign the value " y" to the undefined symbol SOC_SERIES_NRF52X 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:17: warning: attempt to assign the value " y" to the undefined symbol BT_CTLR_ADVANCED_FEATURES 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:20: warning: attempt to assign the value " y" to the undefined symbol BT_CONN 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:21: warning: attempt to assign the value " y" to the undefined symbol BT_LL_SW 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:23: warning: attempt to assign the value " y" to the undefined symbol BT_HCI 
Parsing Kconfig tree in /home/swap/zephyr/Kconfig
Using /home/swap/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/swap/zephyr/samples/bluetooth/beacon/prj.conf
 
warning: BT_CTLR_DATA_LENGTH was assigned the value "y" but got the value "n" -- check dependencies
 
warning: BT_CTLR_DATA_LENGTH_MAX was assigned the value "251" but got the value "" -- check dependencies
 
what could be the correct configurations to enable 251 byte payload?
 
Thank you in advance,
 
regards,
swapnil


payload 251 byte with beacon sample

swapnil <swapnil2007kadam@...>
 

HELLO, 
i am new to zephyr.  and trying to send a message with 251 byte payload. how can I set the controller.? 
 
i am using following configuration:
CONFIG_BT=y
CONFIG_BT_CTLR = y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_DEVICE_NAME="Test beacon"
CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_BT_DEBUG_MONITOR=y
CONFIG_BT_DEBUG_HCI_CORE=y
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_BROADCASTER=y
CONFIG_BT_DEBUG_HCI_DRIVER=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CONN = y
CONFIG_BT_LL_SW = y
BT_CTLR_DATA_LENGTH_MAX = y
CONFIG_BT_HCI = y
CONFIG_SOC_SERIES_NRF52X = y
CONFIG_BT_CTLR_ADVANCED_FEATURES = y
 
 
but it throws following warnings:
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:15: warning: attempt to assign the value " y" to the undefined symbol SOC_SERIES_NRF52X 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:17: warning: attempt to assign the value " y" to the undefined symbol BT_CTLR_ADVANCED_FEATURES 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:20: warning: attempt to assign the value " y" to the undefined symbol BT_CONN 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:21: warning: attempt to assign the value " y" to the undefined symbol BT_LL_SW 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:23: warning: attempt to assign the value " y" to the undefined symbol BT_HCI 
Parsing Kconfig tree in /home/swap/zephyr/Kconfig
Using /home/swap/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/swap/zephyr/samples/bluetooth/beacon/prj.conf
 
warning: BT_CTLR_DATA_LENGTH was assigned the value "y" but got the value "n" -- check dependencies
 
warning: BT_CTLR_DATA_LENGTH_MAX was assigned the value "251" but got the value "" -- check dependencies
 
what could be the correct configurations to enable 251 byte payload?
 
Thank you in advance,
 
regards,
swapnil
 
 
 
 


Re: BLE Nano 2 - LWM2M DTLS demo example

Christos Vasilakis
 

Hi Michael,

Thank you for the detailed step-by-step, greatly appreciated!

It’s working :) 

You are correct, modifying the CONFIG_MBEDTLS_HEAP_SIZE caused the demo to stop working. 

Further, just to point out for other devs coming to this thread, you need to be carefully to issue both of the following commands, one after the other, without a long time gap between them. In my case, I issued the first command, and then notice in the serial logs that I was getting out of memory error. So started to modify the config and eventually modifying also the CONFIG_MBEDTLS_HEAP_SIZE (which further crippled the demo). For reference, a working DTLS config file that I have used, can be found here [1]

$ echo "connect E0:0F:F1:29:76:01 2" > /sys/kernel/debug/bluetooth/6lowpan_control
$ ip address add 2001:db8::2/64 dev bt0

Regarding the suggested changes of moving DTLS and Bluetooth specific settings from "prj.conf" into several config files, makes sense, especially for a newcomer like me.

Regards,

-Christos




On 24 Apr 2018, at 00:16, Michael Scott <michael@...> wrote:

Hi again Christos,


On 04/23/2018 09:34 AM, Christos Vasilakis wrote:
Hi there,

I have recently purchased a BLE Nano 2 kit and I am trying to run the LWM2M client example found here [1]. I have successfully installed and run the simple (non-DTLS) example and works just fine (using a Raspberry PI  6lowpan BLE network as described in [2]). That is, I can successfully ping the Nano node as well as having it register with the Leshan LWM2M server and query it’s objects.

Now I am trying to setup the DTLS example and for this I have done the following:

- setup the pre-shared key on the Leshan server (as suggested in [3])
- enable the dlls configuration in the prj_dtls.conf. A dump of this configuration file can be found here [4]. 

>> Please note that I have lowered the CONFIG_MBEDTLS_HEAP_SIZE from 8192 to 4096 cause I got the following error printed in the console which resulted in a none working BT connection.

I think changing the CONFIG_MBEDTLS_HEAP_SIZE is what's causing the issues you're seeing.  I didn't get the "Unable to get TX packet, not enough memory." error when leaving the CONFIG_MBEDTLS_HEAP_SIZE and using the following changes:


1. Add the following CONFIG lines to the bottom of the prj_dtls.conf:
CONFIG_NET_L2_BT=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NET_APP_BT_NODE=y

2. Build the sample for BLENano2 like so:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj_dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

3. NOTE: The host machine where I connect the BLENano2 via 6lowpan has a Leshan server connected to 2001:db8::2.  I'm assuming you have this running on your RPi.

4. I added the following information to the Leshan security settings:
Client endpoint: nrf52_blenano2
Security mode: Pre-Shared Key (already set by default)
Identity: Client_identity
Key: 000102030405060708090a0b0c0d0e0f

5. When monitoring the BLENano2 via UART, it should spew just a few lines like the Zephyr version and some initialization regaring LwM2M objects and then wait until joined via 6lowpan before attempting to connect to the Leshan server.  Also, you use the "net iface" shell command to see detailed information about the bluetooth network interface.

6. NOTE: Almost all of the RAM on BLENano2 is used by the sample when DTLS enabled (using the default configs).  If you were to enable almost ANY debug CONFIG at all, you would most certainly hit RAM issues.  To help with, you could consider disabling some of the following CONFIG items in prj_dtls.conf:
CONFIG_NET_IPV4=n
CONFIG_NET_APP_NEED_IPV4=n
CONFIG_SYS_LOG_SHOW_COLOR=n

Or tone down the logging output of the sample or disabling the command shell:
CONFIG_NET_LOG=n
CONFIG_NET_BUF_LOG=n
CONFIG_SYS_LOG_NET_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_NET_BUF_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_LWM2M_LEVEL <lowering the # would reduce logging output>
CONFIG_NET_SHELL=n

Let me know how this works on your end.

One last note: I think your experience proves it's too difficult to configure the LwM2M client for extended use-cases (DTLS + Bluetooth networking).  I'm going to submit some patches keeping just the primary "prj.conf" file, move just the DTLS specific settings from "prj_dtls.conf" into "overlay-dtls.conf" and having the Bluetooth enabling configs in "overlay-bt.conf".

This should be easier to maintain over time, *and* hopefully allow more build combinations using the -DCONF_FILE command line option which can take several filenames.
Building and flashing the DTLS-enabled client for BLENano2 would then look something like:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj.conf overlay-bt.conf overlay-dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

- Mike

'[lib/lwm2m_engine] [ERR] lwm2m_init_message: Unable to get TX packet, not enough memory."


Unfortunately the DTLS version doesn’t seem to work. In particular during bootstrap I get error (-72). Here is a dump of the console:

--------------------------------------------------------
***** Booting Zephyr OS v1.11.0-758-g541c3cb18 *****
[lib/lwm2m_engine] [DBG] lwm2m_engine_init: LWM2M engine thread started
[lwm2m_obj_security] [DBG] security_create: Create LWM2M security instance: 0
[lwm2m_obj_server] [DBG] server_create: Create LWM2M server instance: 0
[lwm2m_obj_device] [DBG] device_create: Create LWM2M device instance: 0
[lwm2m_obj_firmware] [DBG] firmware_create: Create LWM2M firmware instance: 0
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: e0:0f:f1:29:76:01 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[lwm2m-client] [INF] main: Run LWM2M client
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/0, value:0x0002f852, len:6
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/1, value:0x0002f85f, len:23
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/2, value:0x0002f87d, len:9
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/3, value:0x0002f88d, len:3
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/9, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/10, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/17, value:0x0002f8b0, len:16
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/18, value:0x0002f8c8, len:5
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/20, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/21, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3303/0
[ipso_temp_sensor] [DBG] temp_sensor_create: Create IPSO Temperature Sensor instance: 0
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3303/0/5700, value:0x2000c310, len:8
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3311/0
[ipso_light_control] [DBG] light_control_create: Create IPSO Light Control instance: 0
prio recv thread stack (real size 748): unused 488      usage 260 / 748 (34 %)
recv thread stack (real size 1324):     unused 424      usage 900 / 1324 (67 %)
[lib/lwm2m_engine] [ERR] lwm2m_engine_start: Cannot connect UDP (-72)
[lib/lwm2m_rd_client] [ERR] lwm2m_rd_client_start: Cannot init LWM2M engine (-72)
[lwm2m-client] [ERR] main: LWM2M init LWM2M RD client error (-72)
prio
--------------------------------------------------------


From the Raspberry PI I can successfully ping the node which implies that connectivity exists and is working.

root@raspberrypi:/home/pi# ping 2001:db8::1. <— BLE Nano 2 
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=221 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=194 ms
^C
--- 2001:db8::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 194.834/208.153/221.472/13.319 ms


I would be grateful if someone can help me to debug the issue.

Thank you in advance

-Christos





Re: BLE Nano 2 - LWM2M DTLS demo example

Michael Scott
 

Hi again Christos,


On 04/23/2018 09:34 AM, Christos Vasilakis wrote:
Hi there,

I have recently purchased a BLE Nano 2 kit and I am trying to run the LWM2M client example found here [1]. I have successfully installed and run the simple (non-DTLS) example and works just fine (using a Raspberry PI  6lowpan BLE network as described in [2]). That is, I can successfully ping the Nano node as well as having it register with the Leshan LWM2M server and query it’s objects.

Now I am trying to setup the DTLS example and for this I have done the following:

- setup the pre-shared key on the Leshan server (as suggested in [3])
- enable the dlls configuration in the prj_dtls.conf. A dump of this configuration file can be found here [4]. 

>> Please note that I have lowered the CONFIG_MBEDTLS_HEAP_SIZE from 8192 to 4096 cause I got the following error printed in the console which resulted in a none working BT connection.

I think changing the CONFIG_MBEDTLS_HEAP_SIZE is what's causing the issues you're seeing.  I didn't get the "Unable to get TX packet, not enough memory." error when leaving the CONFIG_MBEDTLS_HEAP_SIZE and using the following changes:

1. Add the following CONFIG lines to the bottom of the prj_dtls.conf:
CONFIG_NET_L2_BT=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NET_APP_BT_NODE=y

2. Build the sample for BLENano2 like so:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj_dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

3. NOTE: The host machine where I connect the BLENano2 via 6lowpan has a Leshan server connected to 2001:db8::2.  I'm assuming you have this running on your RPi.

4. I added the following information to the Leshan security settings:
Client endpoint: nrf52_blenano2
Security mode: Pre-Shared Key (already set by default)
Identity: Client_identity
Key: 000102030405060708090a0b0c0d0e0f

5. When monitoring the BLENano2 via UART, it should spew just a few lines like the Zephyr version and some initialization regaring LwM2M objects and then wait until joined via 6lowpan before attempting to connect to the Leshan server.  Also, you use the "net iface" shell command to see detailed information about the bluetooth network interface.

6. NOTE: Almost all of the RAM on BLENano2 is used by the sample when DTLS enabled (using the default configs).  If you were to enable almost ANY debug CONFIG at all, you would most certainly hit RAM issues.  To help with, you could consider disabling some of the following CONFIG items in prj_dtls.conf:
CONFIG_NET_IPV4=n
CONFIG_NET_APP_NEED_IPV4=n
CONFIG_SYS_LOG_SHOW_COLOR=n

Or tone down the logging output of the sample or disabling the command shell:
CONFIG_NET_LOG=n
CONFIG_NET_BUF_LOG=n
CONFIG_SYS_LOG_NET_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_NET_BUF_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_LWM2M_LEVEL <lowering the # would reduce logging output>
CONFIG_NET_SHELL=n

Let me know how this works on your end.

One last note: I think your experience proves it's too difficult to configure the LwM2M client for extended use-cases (DTLS + Bluetooth networking).  I'm going to submit some patches keeping just the primary "prj.conf" file, move just the DTLS specific settings from "prj_dtls.conf" into "overlay-dtls.conf" and having the Bluetooth enabling configs in "overlay-bt.conf".

This should be easier to maintain over time, *and* hopefully allow more build combinations using the -DCONF_FILE command line option which can take several filenames.
Building and flashing the DTLS-enabled client for BLENano2 would then look something like:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj.conf overlay-bt.conf overlay-dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

- Mike

'[lib/lwm2m_engine] [ERR] lwm2m_init_message: Unable to get TX packet, not enough memory."


Unfortunately the DTLS version doesn’t seem to work. In particular during bootstrap I get error (-72). Here is a dump of the console:

--------------------------------------------------------
***** Booting Zephyr OS v1.11.0-758-g541c3cb18 *****
[lib/lwm2m_engine] [DBG] lwm2m_engine_init: LWM2M engine thread started
[lwm2m_obj_security] [DBG] security_create: Create LWM2M security instance: 0
[lwm2m_obj_server] [DBG] server_create: Create LWM2M server instance: 0
[lwm2m_obj_device] [DBG] device_create: Create LWM2M device instance: 0
[lwm2m_obj_firmware] [DBG] firmware_create: Create LWM2M firmware instance: 0
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: e0:0f:f1:29:76:01 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[lwm2m-client] [INF] main: Run LWM2M client
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/0, value:0x0002f852, len:6
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/1, value:0x0002f85f, len:23
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/2, value:0x0002f87d, len:9
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/3, value:0x0002f88d, len:3
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/9, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/10, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/17, value:0x0002f8b0, len:16
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/18, value:0x0002f8c8, len:5
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/20, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/21, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3303/0
[ipso_temp_sensor] [DBG] temp_sensor_create: Create IPSO Temperature Sensor instance: 0
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3303/0/5700, value:0x2000c310, len:8
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3311/0
[ipso_light_control] [DBG] light_control_create: Create IPSO Light Control instance: 0
prio recv thread stack (real size 748): unused 488      usage 260 / 748 (34 %)
recv thread stack (real size 1324):     unused 424      usage 900 / 1324 (67 %)
[lib/lwm2m_engine] [ERR] lwm2m_engine_start: Cannot connect UDP (-72)
[lib/lwm2m_rd_client] [ERR] lwm2m_rd_client_start: Cannot init LWM2M engine (-72)
[lwm2m-client] [ERR] main: LWM2M init LWM2M RD client error (-72)
prio
--------------------------------------------------------


From the Raspberry PI I can successfully ping the node which implies that connectivity exists and is working.

root@raspberrypi:/home/pi# ping 2001:db8::1. <— BLE Nano 2 
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=221 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=194 ms
^C
--- 2001:db8::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 194.834/208.153/221.472/13.319 ms


I would be grateful if someone can help me to debug the issue.

Thank you in advance

-Christos



2361 - 2380 of 3111