Notifications, Security & Bonding.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I'm trying to get a notification service up & going. The App I've got is unreliable in it's ability to successfully sign up for, & receive notification data.

The code I've got so far receives a 10 byte packet from another µC every second. It then tries to push that data via a Vendor Specific Notification service created by the Smart Designer. The code doesn't request or enable security. (    /*.encr_required                  =*/ 0,    //(SECURITY_ENABLED | SECURITY_REQUEST),    // data encrypted and device sends security request on every connection)

Below is an annotated trace dump showing my App unsuccessfully signing up for notifications & then retrying resulting in success.

16:18:56 -

16:18:56 - Pckt(10):ba00 & 4a93

Packet received by Broadcom from MSP, size 10 bytes.

16:18:56 - timeout:29

16:18:57 -

16:18:57 - Pckt(10):bb00 & 4a93

16:18:57 - timeout:30

16:18:58 -

16:18:58 - Pckt(10):bc00 & 4a93

16:18:58 - timeout:31

Broadcoms 1s timer

16:18:59 -

16:18:59 - Pckt(10):bd00 & 4a93

16:18:59 - timeout:32

16:19:00 -

16:19:00 - Pckt(10):be00 & 4a93

16:19:00 - timeout:33

16:19:01 -

16:19:01 - Pckt(10):bf00 & 4a93

16:19:01 - timeout:34

16:19:02 -

16:19:02 - Pckt(10):c000 & 4a93

16:19:02 - timeout:35

16:19:03 -

16:19:03 - Pckt(10):c100 & 4a93

16:19:03 - timeout:36

16:19:04 -

16:19:04 - connection_up: 78a8735dd09b h=64

First Connection since programming.

16:19:04   Connection is UP.

16:19:04   profile idle timer stop

16:19:04   connUp

16:19:04   noAdv

16:19:04   noAdv

16:19:04 - Pckt(10):c200 & 4a93

NB: because no other messages appear here the Broadcom is not attempting to send any data because no "bonded peer" has been located.

16:19:04 - timeout:37

16:19:05 -

16:19:05 - Pckt(10):c300 & 4a93

16:19:05 - timeout:38

16:19:06 -

16:19:06 - Pckt(10):c400 & 4a93

16:19:06 - timeout:39

16:19:07 -

16:19:07 - Pckt(10):c500 & 4a93

16:19:07 - timeout:40

16:19:08 -

16:19:08 - Pckt(10):c600 & 4a93

16:19:08 - timeout:41

16:19:09 -

16:19:09 - Pckt(10):c700 & 4a93

16:19:09 - timeout:42

16:19:10 -

16:19:10 - Pckt(10):c800 & 4a93

16:19:10 - timeout:43

16:19:11 -

16:19:11 - Pckt(10):c900 & 4a93

16:19:11 - timeout:44

16:19:12 -

16:19:12 - Pckt(10):ca00 & 4a93

16:19:12 - timeout:45

16:19:13 -

16:19:13 - Pckt(10):cb00 & 4a93

16:19:13 - timeout:46

16:19:14 -

16:19:14 - Pckt(10):cc00 & 4a93

16:19:14 - timeout:47

16:19:15 -

16:19:15 - Pckt(10):cd00 & 4a93

16:19:15 - timeout:48

16:19:16 -

16:19:16 - Pckt(10):ce00 & 4a93

16:19:16 - timeout:49

16:19:17 -

16:19:17 - Pckt(10):cf00 & 4a93

16:19:17 - timeout:50

16:19:18 -

16:19:18 - Pckt(10):d000 & 4a93

16:19:18 - timeout:51

16:19:19 -

16:19:19 - Pckt(10):d100 & 4a93

16:19:19 - timeout:52

16:19:20 -

16:19:20 - Pckt(10):d200 & 4a93

16:19:20 - timeout:53

16:19:21 -

16:19:21 - Pckt(10):d300 & 4a93

16:19:21   smp timer started 00

First attempt to sign up for Notifications.

16:19:21 - timeout:54

16:19:21 -

16:19:21   SMPTmrRef

16:19:21   SMPTmrRef

16:19:22 - encryption changed 78a8735dd09b

16:19:22   SMPTmrRef

16:19:22   SMPTmrRef

16:19:22   SMPTmrRef

16:19:22   SMPTmrRef

16:19:22   SMPTmrRef

16:19:22   SMPTmrStp

16:19:22 - Pckt(10):d400 & 4a93

16:19:22 - smp_bond_result 03

Successful bonding

16:19:22 - NVRAM write:0018

Writing Bonding data to non-volatile RAM on Broadcom.

16:19:22 - timeout:55

16:19:23 -

16:19:23 - Pckt(10):d500 & 4a93

16:19:23 - don't notify handle:811

(This is the extra message that we didn't see earlier) Now the notification function has located a "bonded peer" but as far as it knows that peer hasn't signed up for notifications.

16:19:23 - don't notify handle:541

16:19:23 - timeout:56

16:19:24 -

16:19:24 - Pckt(10):d600 & 4a93

16:19:24 - don't notify handle:811

16:19:24 - don't notify handle:541

16:19:24 - timeout:57

16:19:25 -

16:19:25 - Pckt(10):d700 & 4a93

16:19:25 - don't notify handle:811

16:19:25 - don't notify handle:541

16:19:25 - timeout:58

16:19:26 -

16:19:26 - Pckt(10):d800 & 4a93

16:19:26 - don't notify handle:811

16:19:26 - don't notify handle:541

16:19:26 - timeout:59

16:19:27 -

16:19:27 - Pckt(10):d900 & 4a93

16:19:27 - don't notify handle:811

16:19:27 - don't notify handle:541

16:19:27 - write_handler: handle 0550

This is where the notifications checkbox, which is ticked from the first touch is pressed again unchecking the box, i.e. writing "0" to HDLD_ALERTS_CLIENT_CONFIGURATION (0550)

16:19:27 - handle:550 val:0000

16:19:27 - NVRAM write:0018

16:19:27   WriteCb: handle 0000

16:19:27 - timeout:60

16:19:28 -

16:19:28 - Pckt(10):da00 & 4a93

16:19:28 - don't notify handle:811

16:19:28 - don't notify handle:541

16:19:28 - timeout:61

16:19:29 -

16:19:29 - Pckt(10):db00 & 4a93

16:19:29 - don't notify handle:811

16:19:29 - don't notify handle:541

16:19:29 - timeout:62

16:19:30 -

16:19:30 - write_handler: handle 0550

2nd attempt to sign up for notifications Now the notifications checkbox on the Broadcom is pressed again, "checking" the box, writing "1"

16:19:30 - handle:550 val:0001

16:19:30 - NVRAM write:0018

16:19:30   WriteCb: handle 0000

16:19:30 - Pckt(10):dc00 & 4a93

16:19:30 - don't notify handle:811

16:19:30 - notify len:10 handle:541

Now that a bonded peer is found & that peer has signed up for notifications, data is sent reliably between connections & disconnections.

16:19:30 - timeout:63

16:19:31 -

16:19:31 - Pckt(10):dd00 & 4a93

16:19:31 - don't notify handle:811

16:19:31 - notify len:10 handle:541

16:19:31 - timeout:64

16:19:32 -

16:19:32 - Pckt(10):de00 & 4a93

16:19:32 - don't notify handle:811

16:19:32 - notify len:10 handle:541

16:19:32 - timeout:65

16:19:33 -

16:19:33 - Pckt(10):df00 & 4a93

16:19:33 - don't notify handle:811

16:19:33 - notify len:10 handle:541

16:19:33 - timeout:66

16:19:34 -

16:19:34 - Pckt(10):e000 & 4a93

16:19:34 - don't notify handle:811

16:19:34 - notify len:10 handle:541

16:19:34 - timeout:67

16:19:35 -

16:19:35 - Pckt(10):e100 & 4a93

16:19:35 - don't notify handle:811

16:19:35 - notify len:10 handle:541

16:19:35 - timeout:68

16:19:36 -

16:19:36 - Pckt(10):e200 & 4a93

16:19:36 - don't notify handle:811

16:19:36 - notify len:10 handle:541

16:19:36 - timeout:69

16:19:38 -

16:19:38 - Pckt(10):e300 & 4a93

16:19:38 - don't notify handle:811

16:19:38 - notify len:10 handle:541

16:19:38 - timeout:70

So it looks like the first attempt to sign up for notifications from the app resulted in a lesmp_sendSecurityRequest(). Is this expected behaviour when encr_required = 0?

0 Likes
1 Solution

I agree with boont that you should look at what hello_sensor app is doing.  Hopefully it will give you some clue.  By the way, the encr_required flag is not processed anyway by the stack.  The variable is completely in your control and you can use it the way you want.  Similarly it is up to you if you want to send lmp_sendSecurityRequest.  You should do it if you want data to be encrypted.  Alternatively you can just add appropriate permission to a characteristic.  For example if you add LEGATTDB_PERM_AUTH_READABLE to a characteristic, when client tries to read it, the stack will return appropriate error code, the client will setup encryption and then try reading it again.

View solution in original post

0 Likes
2 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

i couldn't pinpoint why but i would refer to the hello-sensor app as a golden reference to check against your app.

0 Likes

I agree with boont that you should look at what hello_sensor app is doing.  Hopefully it will give you some clue.  By the way, the encr_required flag is not processed anyway by the stack.  The variable is completely in your control and you can use it the way you want.  Similarly it is up to you if you want to send lmp_sendSecurityRequest.  You should do it if you want data to be encrypted.  Alternatively you can just add appropriate permission to a characteristic.  For example if you add LEGATTDB_PERM_AUTH_READABLE to a characteristic, when client tries to read it, the stack will return appropriate error code, the client will setup encryption and then try reading it again.

0 Likes