3 Replies Latest reply on Mar 1, 2018 7:48 AM by epr_1639216

    Link-Layer (LL) Privacy on the Central-side

      I've used the BLE_4.2_DataLength_Security_Privacy example almost verbatim on the Peripheral-side, and, after dabbling a bit on the Central-side, have gotten the 2 (both PSOC4 Modules) to Connect->Auth->Bond with each other. Now, however, just like the Example, I want the Peripheral to Directly advertise with a RPA.


      I'm pretty sure the criteria is correct there, so, since I don't have an example for the Central-side, I'm assuming there is something I'm missing in that code.


      What's happening is that a CYBLE_EVT_GAPC_DIRECT_ADV_REPORT is not even hitting when the Peripheral advertises.  Since its direct and RPA, no device, CySmart dongle or other, is catching the Peripheral, but the Central is scanning other floating devices, so I'm sure scanning is working.


      What API functions need to be called on the Central, during/after pairing/bonding, to ensure LL Privacy is implemented correctly?


      Troubleshooting Update:

      A little additional Info (Some may matter, other highlights FYI):

      • The Central is a Central/Peripheral setup, though broadcaster only as of yet.
      • After StoreBond, both devices would update information within their local Device Information service.  At first, I would call CyBle_StoreStackData, but the, on only the Central-end, I would get a CYBLE_HCI_COMMAND_DISALLOWED_ERROR.  Figuring it must be that, I took CyBle_StoreStackData out, with no luck, then I called CyBle_Stop() and restarted the stack after 'Bonding Mode' was complete.  I know I shouldn't have to do that, but didn't know what I was calling the cause the vague error.  I'm disconnected for the CyBle_StoreBondingData(), so the only command was StartAdvertisement.
      • I tested a CyBle_Stop/Start call on the Peripheral end as well to see if it would resolve any issues, but all it did was wipe out any RPA it constructed when it went into and came out of Low Power Mode.

      UPDATE 2:  Central Module is CYBLE-202007, and after reading up, I'm now doing a soft reset on just that end after the bonding procedure is complete.  On re-initializing, Bonds read up fine, and scanning/advertising starts up as well.  Now, the major issue is what it has been all along:  Peripheral is Directly advertising, Central does NOT see it.  Central has been catching Direct Advertisements from other devices within range.  No addresses in the advertisement package is related to either device.  I'm not sure if that should happen, since I've always assumed CYBLE_EVT_GAPC_DIRECT_ADV_REPORT was only hit when the device was being advertised to directly and only on that device.

        • 1. Re: Link-Layer (LL) Privacy on the Central-side

          If the PSoC device is configured to require bonding, then you will need to bond on each connection for more access.

          Otherwise, the function API CyBle_GapAuthReq() should be the start of initiating security/pairing/bonding. Then, you just need to handle the events/sequence of events that follows.

          • 2. Re: Link-Layer (LL) Privacy on the Central-side

            I've changed the Peripheral's advType from CYBLE_GAPP_CONNECTABLE_LOW_DC_DIRECTED_ADV to CYBLE_GAPP_CONNECTABLE_UNDIRECTED_ADV and Added the Central to Whitelist.  I'm still working out kinks, but would you happen to know why Central couldn't scan the Peripheral set at CYBLE_GAPP_CONNECTABLE_LOW_DC_DIRECTED_ADV? 

            • 3. Re: Link-Layer (LL) Privacy on the Central-side

              Directed advertising is an advertisement packet aimed at a specific BLE recipient. So, instead of the recipient being any BLE devices in range, most BLE devices will filter directed advertisements if they aren't the recipient. This means that the directed advertisement needs to have the BD address of the device scanning set as the recipient of the directed advertisements in order for your Central device to see it (by default).


              (You're right, the central device shouldn't be picking up directed advertisement packets unless it is not set to ignore the direct advertisement packets of other device addresses)

              Essentially, it's like saying the packet is intended for central device xxx-xxx-xxx, but that doesn't mean other devices can't still read the message (as advertisements have no privacy/security by implementation)


              If you turn the directed advertisement back on, and set the advertisement address to the Central device's address, I would expect you to be able to see only the directed advertisements from the peripheral.


              P.S. The LOW_DC might be an effect too, but I'm not sure what the LOW_DC implies from my experience with the PSoC 4 module besides the antenna potentially having a specific electrical/hardware difference in power and/or AC vs. DC