2 Replies Latest reply on Apr 1, 2015 2:40 PM by VictorZ_46

    Notifications, Security & Bonding.

      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?

        • 1. Re: Notifications, Security & Bonding.
          BoonT_56

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

          • 2. Re: Notifications, Security & Bonding.
            VictorZ_46

            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.