Date   

Re: How does the app get notified if authentication failed?

Li, Jun R
 

Hi Johan,
Thanks for help!

It seems the function " pairing_complete" in your proposal is enough to cover both failure and success cases, with the parameter "bool bonded", right?

And I'm not sure why it is not proper to place the new api function in the API " bt_conn_auth_cb". Can you explain it a bit more?

Sure I'll create a new issue to request this.

Regards,
Jun


On 6/14/18, 02:58, "Johan Hedberg" <johan.hedberg@...> wrote:

Hi Jun,

On Wed, Jun 13, 2018, Li, Jun R wrote:
> In my BLE project, a passkey is required to access the NRF51 device;
> thus the callback functions of “struct bt_conn_auth_cb” were
> implemented to achieve secured paring. What I observed is that
>
> 1. The function “cancel” will be called if the other peer canceled
> the pairing process.
> 2. The function “security_changed” will be called if the passkey
> was successfully entered.

The second one is a bit ambiguous, since it'll also be called for
subsequent connections when the connection gets encrypted, even though
pairing is not in progress (it already happened over some earlier
connection).

> However, my application was NOT notified if a wrong passkey was
> entered, thus the BLE connection is still kept. Ideally, I hope to
> immediately disconnect the connection if the passkey is wrong.
> However, I can’t find a callback function to notify the application if
> the passkey was wrong.
>
> With more debugging logs, I can see the function
> “smp_pairing_complete” got status (-4) when pairing failed while this
> status is zero when successful.
>
> Can anyone enlighten me what kind of function can be used to notify
> the application that pairing failed? Thank you!

This seems to be an oversight in the API. I'd propose to add two new
entries to bt_conn_auth_cb, something like the following:

void (*pairing_complete)(struct bt_conn *conn, bool bonded);
void (*pairing_failed)(struct bt_conn *conn);

For the second one we might want to add another parameter for the
reason. An SMP error comes to mind, but then that wont be reusable for
BR/EDR (which we have experimental support for).

Actually, now that I think about it, bt_conn_auth_cb could be
problematic since it's possible to do just-works pairing without
registering such a structure. I wonder if our bt_conn_cb would be
better. That said, these callbacks are strictly about pairing..

Could you open a github issue to track this, so we get it done for 1.13?

Johan


Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Carles Cufi
 

Yes, that is exactly it.

In that case I am not sure about the issue. Perhaps Johan can bring some light into it.

 

Carles

 

From: "Li, Jun R" <jun.r.li@...>
Date: Thursday, 14 June 2018 at 17:32
To: "Cufi, Carles" <Carles.Cufi@...>, "devel@..." <devel@...>
Subject: Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Yes, every time when I did the tests, I let iPhone “forget the device”, which I suppose to erase the bond info, right?

 

Regards,

Jun

 

 

From: "Cufi, Carles" <Carles.Cufi@...>
Date: Thursday, June 14, 2018 at 08:29
To: Jun Li <jun.r.li@...>, "devel@..." <devel@...>
Subject: RE: Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi there,

 

Have you tried erasing the bond from iOS settings? I find that sometimes bonding fails if the device is already bonded, for whatever reason.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Li, Jun R
Sent: 14 June 2018 17:23
To: devel@...
Subject: [Zephyr-devel] Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi everyone,

 

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

 

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

 

 

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

 

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

 

More logs can be referred below. Thank you!

 

Regards,

Jun

 

 

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

 

 

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8


Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Li, Jun R
 

Yes, every time when I did the tests, I let iPhone “forget the device”, which I suppose to erase the bond info, right?

 

Regards,

Jun

 

 

From: "Cufi, Carles" <Carles.Cufi@...>
Date: Thursday, June 14, 2018 at 08:29
To: Jun Li <jun.r.li@...>, "devel@..." <devel@...>
Subject: RE: Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi there,

 

Have you tried erasing the bond from iOS settings? I find that sometimes bonding fails if the device is already bonded, for whatever reason.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Li, Jun R
Sent: 14 June 2018 17:23
To: devel@...
Subject: [Zephyr-devel] Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi everyone,

 

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

 

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

 

 

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

 

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

 

More logs can be referred below. Thank you!

 

Regards,

Jun

 

 

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

 

 

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8


Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Carles Cufi
 

Hi there,

 

Have you tried erasing the bond from iOS settings? I find that sometimes bonding fails if the device is already bonded, for whatever reason.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Li, Jun R
Sent: 14 June 2018 17:23
To: devel@...
Subject: [Zephyr-devel] Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi everyone,

 

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

 

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

 

 

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

 

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

 

More logs can be referred below. Thank you!

 

Regards,

Jun

 

 

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

 

 

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8


Different BLE pairing behaviors on iPhone 6 and iPhone 7

Li, Jun R
 

Hi everyone,

 

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

 

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

 

 

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

 

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

 

More logs can be referred below. Thank you!

 

Regards,

Jun

 

 

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

 

 

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8


BLE slave pair/bond flow

Theis Orthmann Blickfeldt Jørgensen (TTJO)
 

Hi,

 

I am currently trying to map our current BLE GAP API to Zephyr BT API, but I find it a little bit unclear how the pairing/bonding flow is supposed to work on the slave side.

 

From the sample-code it looks like you simply are supposed to enable BT and register the CB-functions. Then you will get connected-CB when a device has connected -> followed by a security_changed-CB when/if the master has paired with the slave. PLEASE CORRECT ME IF I AM WRONG OR MISSING STEPS!

 

But what is the slave-side use-case for bt_conn_create_slave_le(…), and where does it fit in process above?

 

Venlig hilsen/kind regards

Theis Orthmann Blickfeldt Jørgensen

Embedded Software Developer, M.Sc.EE.

 

Oticon A/S

Kongebakken 9

DK-2765 Smørum

 

ttjo@...

www.oticon.com

 


Re: Documentation on bt_conn_auth_cb(...)

Theis Orthmann Blickfeldt Jørgensen (TTJO)
 

Thank you,

however it is not ideal that one should read/understand the SMP to understand when a given CB is expected to occour.

I have submitted the issue on GitHub.

\Theis


Re: Documentation on bt_conn_auth_cb(...)

Johan Hedberg
 

Hi Theis,

On Thu, Jun 14, 2018, Theis Orthmann Blickfeldt Jørgensen (TTJO) wrote:
I am trying to understand the GAP API for Zephyr Bluetooth Stack, and
came across bt_conn_auth_cb(...). This callback function seems to be
completely undocumented.
Anyone who know what the callback-criteria is for the registered
functions?
They map directly to the authentication methods from the Security
Manager protocol.

If the responsible developers at Intel reads this message, it would be
nice with some explanatory comments in the source code.
The lack of documentation for these is indeed an oversight. Could you
open a github issue so we can track getting the documentation
implemented? Btw, the response functions to the callbacks (the ones that
solicit a response anyway) are at least documented, and describe which
callback from bt_conn_auth_cb they relate to (I'm referring here to the
likes of bt_conn_auth_passkey_entry, bt_conn_auth_passkey_confirm, etc).

Johan


Documentation on bt_conn_auth_cb(...)

Theis Orthmann Blickfeldt Jørgensen (TTJO)
 

Hi,

 

I am trying to understand the GAP API for Zephyr Bluetooth Stack, and came across bt_conn_auth_cb(…). This callback function seems to be completely undocumented.
Anyone who know what the callback-criteria is for the registered functions?

 

If the responsible developers at Intel reads this message, it would be nice with some explanatory comments in the source code.

 

Venlig hilsen/kind regards

Theis Orthmann Blickfeldt Jørgensen

Embedded Software Developer, M.Sc.EE.

 

Oticon A/S

Kongebakken 9

DK-2765 Smørum

 

ttjo@...

www.oticon.com

 


Re: Adding own Library to project

Sebastian Boe
 

As far as I am able to understand your description, this is expected to work.

Perhaps you could share a minimal patch to an existing sample to demonstrate
when the linker error occurs.

________________________________________
From: devel@... <devel@...> on behalf of König Patrick <Patrick.Koenig@...>
Sent: Thursday, 14 June 2018 10:32:43 AM
To: Li, Jun R; Patrick Boettcher
Cc: zephyr-devel@...; Sittkus Manuel
Subject: Re: [Zephyr-devel] Adding own Library to project

Thanks a lot for your help. I have tried your suggested solution with the CMakeList. Unfortunately, this did not work for me. I got the linker errors as described in my initial mail.

Let me try to illustrate my problem in a bit more detail:

If I add two function to my main.c file, for example usb_send() and usb_receive(), my code works fine. Once I move these functions to independent files like usb_xyz.c for the source and usb_xyz.h for the headers and include the header file in the main.c file, I am no longer able to link my project.

Usually I just need to include usb_xyz.h to my main.c file and add the usb_xyz.c and usb_xyz.h to a Makefile. With Cmake however, I added the usb_xyz.c file to the CMakelist and included header file in my main.c file, which leaves me with linker errors, like undefined reference to usb_send() and usb_receive().
I checked the compiler output, and saw the following line: “Building C object CMakeFiles/app.dir/src/usb_xyz.c.obj”, which leads me to believe that the file was compiled.

I hope this example makes my issue a bit clearer. Basically I just want to create modular Code that I can reuse in other zephyr projects as well.

Regards,

Patrick



-----Ursprüngliche Nachricht-----
Von: Li, Jun R [mailto:jun.r.li@...]
Gesendet: Mittwoch, 13. Juni 2018 16:59
An: Patrick Boettcher <patrick.boettcher@...>
Cc: König Patrick <Patrick.Koenig@...>; zephyr-devel@...; Sittkus Manuel <Manuel.Sittkus@...>
Betreff: Re: [Zephyr-devel] Adding own Library to project

That is true, this way doesn't support adding a driver module into the application since the app doesn't directly call anything from the driver. I'm wondering why driver modules in zephyr directory can be linked even without specifying dependency relationship. How is a driver module in Zephyr directory linked together?


On 6/13/18, 07:53, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

On Wed, 13 Jun 2018 14:45:43 +0000
"Li, Jun R" <jun.r.li@...> wrote:

> Hi Patrick,
>
> If you still want to keep your library (module), another way you can
> do is to add your library as the link dependency for the application
> library (app) by the following:
>
> target_link_libraries(app your_lib_name)

Well, this way of doing bears a whole of problems in some conditions.

While it works in probably most cases, including drivers in such a
library won't work.

Link-order sometimes messes up things as well if your library requires
zephyr functions from libraries where explicit dependencies was
not/could not be declared.

Sebastian is working on it, there is an issue on github's page for it.

--
Patrick.


Re: Adding own Library to project

König Patrick <Patrick.Koenig@...>
 

Thanks a lot for your help. I have tried your suggested solution with the CMakeList. Unfortunately, this did not work for me. I got the linker errors as described in my initial mail.

Let me try to illustrate my problem in a bit more detail:

If I add two function to my main.c file, for example usb_send() and usb_receive(), my code works fine. Once I move these functions to independent files like usb_xyz.c for the source and usb_xyz.h for the headers and include the header file in the main.c file, I am no longer able to link my project.

Usually I just need to include usb_xyz.h to my main.c file and add the usb_xyz.c and usb_xyz.h to a Makefile. With Cmake however, I added the usb_xyz.c file to the CMakelist and included header file in my main.c file, which leaves me with linker errors, like undefined reference to usb_send() and usb_receive().
I checked the compiler output, and saw the following line: “Building C object CMakeFiles/app.dir/src/usb_xyz.c.obj”, which leads me to believe that the file was compiled.

I hope this example makes my issue a bit clearer. Basically I just want to create modular Code that I can reuse in other zephyr projects as well.

Regards,

Patrick



-----Ursprüngliche Nachricht-----
Von: Li, Jun R [mailto:jun.r.li@...]
Gesendet: Mittwoch, 13. Juni 2018 16:59
An: Patrick Boettcher <patrick.boettcher@...>
Cc: König Patrick <Patrick.Koenig@...>; zephyr-devel@...; Sittkus Manuel <Manuel.Sittkus@...>
Betreff: Re: [Zephyr-devel] Adding own Library to project

That is true, this way doesn't support adding a driver module into the application since the app doesn't directly call anything from the driver. I'm wondering why driver modules in zephyr directory can be linked even without specifying dependency relationship. How is a driver module in Zephyr directory linked together?


On 6/13/18, 07:53, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

On Wed, 13 Jun 2018 14:45:43 +0000
"Li, Jun R" <jun.r.li@...> wrote:

> Hi Patrick,
>
> If you still want to keep your library (module), another way you can
> do is to add your library as the link dependency for the application
> library (app) by the following:
>
> target_link_libraries(app your_lib_name)

Well, this way of doing bears a whole of problems in some conditions.

While it works in probably most cases, including drivers in such a
library won't work.

Link-order sometimes messes up things as well if your library requires
zephyr functions from libraries where explicit dependencies was
not/could not be declared.

Sebastian is working on it, there is an issue on github's page for it.

--
Patrick.


Re: [Zephyr-users] What is the process to enable bluetooth so that nrf52832 is disciverable by other device (android phone) #bluetoothmesh #nrf52832 #ble

vikrant8051 <vikrant8051@...>
 

Hi Rajat,

This could be helpful

You've to make changes as per your Board design.

regards,
vikrant

On Thu, Jun 14, 2018 at 4:14 PM, Rajat Kalyan <rajatkalyan95@...> wrote:
Hey everyone

I have just started working on nrf52832 board. I want to enable the Bluetooth which is their on the board and set it to discoverable mode(if by default,its not)

I couldnot understand a bit of the sample bluetooth codes given.
Can anyone suggest me some procedure to enable the bluetooth and pair it with my mobile phone.

Thanks 



Re: How does the app get notified if authentication failed?

Johan Hedberg
 

Hi Jun,

On Wed, Jun 13, 2018, Li, Jun R wrote:
In my BLE project, a passkey is required to access the NRF51 device;
thus the callback functions of “struct bt_conn_auth_cb” were
implemented to achieve secured paring. What I observed is that

1. The function “cancel” will be called if the other peer canceled
the pairing process.
2. The function “security_changed” will be called if the passkey
was successfully entered.
The second one is a bit ambiguous, since it'll also be called for
subsequent connections when the connection gets encrypted, even though
pairing is not in progress (it already happened over some earlier
connection).

However, my application was NOT notified if a wrong passkey was
entered, thus the BLE connection is still kept. Ideally, I hope to
immediately disconnect the connection if the passkey is wrong.
However, I can’t find a callback function to notify the application if
the passkey was wrong.

With more debugging logs, I can see the function
“smp_pairing_complete” got status (-4) when pairing failed while this
status is zero when successful.

Can anyone enlighten me what kind of function can be used to notify
the application that pairing failed? Thank you!
This seems to be an oversight in the API. I'd propose to add two new
entries to bt_conn_auth_cb, something like the following:

void (*pairing_complete)(struct bt_conn *conn, bool bonded);
void (*pairing_failed)(struct bt_conn *conn);

For the second one we might want to add another parameter for the
reason. An SMP error comes to mind, but then that wont be reusable for
BR/EDR (which we have experimental support for).

Actually, now that I think about it, bt_conn_auth_cb could be
problematic since it's possible to do just-works pairing without
registering such a structure. I wonder if our bt_conn_cb would be
better. That said, these callbacks are strictly about pairing..

Could you open a github issue to track this, so we get it done for 1.13?

Johan


compiling issue for nRF52840_PDK

vikrant8051 <vikrant8051@...>
 

Hi,

I am getting this error.

-- Selected BOARD nrf52840_pca10056
Zephyr version: 1.12.99
Parsing Kconfig tree in /home/vikrant/projects/zephyr/zephyr/Kconfig
Using /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/build/zephyr/.config as base
CMake Warning at /home/vikrant/projects/zephyr/zephyr/cmake/toolchain.cmake:14 (message):
  ZEPHYR_GCC_VARIANT is deprecated, please use ZEPHYR_TOOLCHAIN_VARIANT
  instead
Call Stack (most recent call first):
  /home/vikrant/projects/zephyr/zephyr/cmake/app/boilerplate.cmake:242 (include)
  CMakeLists.txt:3 (include)


-- Generating zephyr/include/generated/generated_dts_board.h
In file included from /home/vikrant/projects/zephyr/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts:8:0,
                 from <command-line>:0:
/home/vikrant/projects/zephyr/zephyr/dts/arm/nordic/nrf52840.dtsi:2:33: fatal error: dt-bindings/i2c/i2c.h: No such file or directory
 #include <dt-bindings/i2c/i2c.h>

                                 ^
compilation terminated.
CMake Error at /home/vikrant/projects/zephyr/zephyr/cmake/dts.cmake:69 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  /home/vikrant/projects/zephyr/zephyr/cmake/app/boilerplate.cmake:268 (include)
  CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!
See also "/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/build/CMakeFiles/CMakeOutput.log".
See also "/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/build/CMakeFiles/CMakeError.log".
Makefile:680: recipe for target 'cmake_check_build_system' failed
make: *** [cmake_check_build_system] Error 1

Please help me to resolve it. ThankYou !!


How does the app get notified if authentication failed?

Li, Jun R
 

Hi,

 

In my BLE project, a passkey is required to access the NRF51 device; thus the callback functions of “struct bt_conn_auth_cb” were implemented to achieve secured paring. What I observed is that

  1. The function “cancel” will be called if the other peer canceled the pairing process.
  2. The function “security_changed” will be called if the passkey was successfully entered.

 

However, my application was NOT notified if a wrong passkey was entered, thus the BLE connection is still kept. Ideally, I hope to immediately disconnect the connection if the passkey is wrong. However, I can’t find a callback function to notify the application if the passkey was wrong. 

 

With more debugging logs, I can see the function  “smp_pairing_complete” got status (-4) when pairing failed while this status is zero when successful.

 

Can anyone enlighten me what kind of function can be used to notify the application that pairing failed?  Thank you!

 

Regards,

Jun

 


Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi Johan, 
Which app you used for testing ?
Is it samples/boards/nrf52/mesh/onoff-app by adding persistent storage support ?

Could you please test it for PR:8296 by removing NVS from it ? 

Thanks!!

On Wed, Jun 13, 2018, 8:11 PM Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

I understood what you meant. And those are the steps I followed. I used
Nordic's new iOS mesh app and used its "node reset" feature. Then I
reprovisioned and after that did a power-cycle. After that the node came
back up as provisioned.

Johan

On Wed, Jun 13, 2018, vikrant8051 wrote:
> Hi Johan,
>
> I've completely removed NVS from my local project.
> Even after that facing same issue.
>
> If you provision & configure -> reset the board -> then it work as
> expected.
>
> But I'm not talking about power reset...I'm talking about Provisioner
> node-reset command.
>
> For e.g.
>
> provision & configured DEVICE using #meshctl  --> send node-reset command
> via #meshctl  --> unprovision state  --> provision & configure it again -->
> now do power reset/ hardware reset -> Here device should be
> in provisioned state but I always found it in Unprovisioned state.
>
>
> Thank You !!
>
> On Wed, Jun 13, 2018 at 7:01 PM, Johan Hedberg <johan.hedberg@...>
> wrote:
>
> > Hi Vikrant,
> >
> > I just tried your exact steps with the mesh_shell app, and it works
> > correctly (i.e. after the power cycle the board comes back as
> > provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
> > your NVS usage is somehow messing with things?
> >
> > Johan
> >
> > On Wed, Jun 13, 2018, Vikrant More wrote:
> > > Hi Johan,
> > >
> > > It is with default #FCB.
> > >
> > > On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...>
> > > wrote:
> > >
> > > > Hi Vikrant,
> > > >
> > > > Is this with NFFS or FCB? I remember testing this with FCB and it
> > worked
> > > > correctly.
> > > >
> > > > Johan
> > > >
> > > > On Wed, Jun 13, 2018, Vikrant More wrote:
> > > > > Hi,
> > > > >
> > > > > Yes, I confirmed my observation. And happening this every time.
> > > > >
> > > > > I also tried it with #nRFMesh app. In that case too, if I do
> > > > > (provision + configuration) -> ( node-reset ) -> (provision +
> > > > > configuration) --> Reset/ Power down the board-> Device found in
> > > > > unprovisioned state.
> > > > >
> > > > > Thank You !!
> > > > >
> > > > > On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...>
> > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > If after complete or partial provisioning, execute *node-reset*
> > command
> > > > > > then in that case I have observe following things :
> > > > > >
> > > > > > 1) Node get reprovision
> > > > > > 2) but after reboot, it boot as unprovisioned device.
> > > > > >
> > > > > > Has anybody observe this ?
> > > > > >
> > > > > > Thank You !!
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
>
>
>


Re: Adding own Library to project

Li, Jun R
 

That is true, this way doesn't support adding a driver module into the application since the app doesn't directly call anything from the driver. I'm wondering why driver modules in zephyr directory can be linked even without specifying dependency relationship. How is a driver module in Zephyr directory linked together?


On 6/13/18, 07:53, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

On Wed, 13 Jun 2018 14:45:43 +0000
"Li, Jun R" <jun.r.li@...> wrote:

> Hi Patrick,
>
> If you still want to keep your library (module), another way you can
> do is to add your library as the link dependency for the application
> library (app) by the following:
>
> target_link_libraries(app your_lib_name)

Well, this way of doing bears a whole of problems in some conditions.

While it works in probably most cases, including drivers in such a
library won't work.

Link-order sometimes messes up things as well if your library requires
zephyr functions from libraries where explicit dependencies was
not/could not be declared.

Sebastian is working on it, there is an issue on github's page for it.

--
Patrick.


Re: Adding own Library to project

Patrick Boettcher <patrick.boettcher@...>
 

On Wed, 13 Jun 2018 14:45:43 +0000
"Li, Jun R" <jun.r.li@...> wrote:

Hi Patrick,

If you still want to keep your library (module), another way you can
do is to add your library as the link dependency for the application
library (app) by the following:

target_link_libraries(app your_lib_name)
Well, this way of doing bears a whole of problems in some conditions.

While it works in probably most cases, including drivers in such a
library won't work.

Link-order sometimes messes up things as well if your library requires
zephyr functions from libraries where explicit dependencies was
not/could not be declared.

Sebastian is working on it, there is an issue on github's page for it.

--
Patrick.


Re: Adding own Library to project

Li, Jun R
 

Hi Patrick,

If you still want to keep your library (module), another way you can do is to add your library as the link dependency for the application library (app) by the following:

target_link_libraries(app your_lib_name)

Regards,
Jun


On 6/13/18, 06:37, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

Hi Patrick,

On Wed, 13 Jun 2018 10:54:57 +0200
König Patrick <Patrick.Koenig@...> wrote:

> Hello,
>
> My name is Patrick König. I am new to zephyr. I just wrote a couple
> of functions as additions to the zephyr/samples/subsys/usb/cdc_acm
> Sample Project for the Nordic nRf52840. These are working fine and
> have been tested.
>
> Now I moved these functions from the main.c file to a custom module
> (.c and .h) within the src folder of my project. While doing so I
> managed to build the object file by keeping the sources in the source
> folder as described in the documentation. Unfortunately I get errors
> from the linker telling me that I have undefined references to my
> functions.

The most convenient way of adding additional sources to your
application outside zephyr is using

target_sources(app PRIVATE src1.c src2.c)

in the CMakeLists.txt of your application (there where you are
including Zephyr's boilerplate.cmake).

I'm not sure whether that answers your question. Feel free to give some
more details and code-example if appropriate.

best regards,
--
Patrick.


Re: [Zephyr-users] #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

I understood what you meant. And those are the steps I followed. I used
Nordic's new iOS mesh app and used its "node reset" feature. Then I
reprovisioned and after that did a power-cycle. After that the node came
back up as provisioned.

Johan

On Wed, Jun 13, 2018, vikrant8051 wrote:
Hi Johan,

I've completely removed NVS from my local project.
Even after that facing same issue.

If you provision & configure -> reset the board -> then it work as
expected.

But I'm not talking about power reset...I'm talking about Provisioner
node-reset command.

For e.g.

provision & configured DEVICE using #meshctl --> send node-reset command
via #meshctl --> unprovision state --> provision & configure it again -->
now do power reset/ hardware reset -> Here device should be
in provisioned state but I always found it in Unprovisioned state.


Thank You !!

On Wed, Jun 13, 2018 at 7:01 PM, Johan Hedberg <johan.hedberg@...>
wrote:

Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...>
wrote:

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it
worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...>
wrote:

Hi,

If after complete or partial provisioning, execute *node-reset*
command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



3801 - 3820 of 8575