Advertisement's whitelist doesn't work in EZ-Serial (and multiple issues related to pairing)

[DaM__2104136]

Hi all,

We want to use the pairing and whitelist features of the BLE module integrated in our product (CYBLE-212019-00 / CYBLE-212020-01). The BLE module is controlled via UART using the EZ-Serial API. The main problem is, when a smartphone is paired with the BLE module (the BLE module acts as peripheral / GATT server), if the whitelist is enabled it is not possible to reconnect the smartphone although bond and whitelist entries exist for the paired device. We followed the recommendations and parameter setting given in the “EZ-Serial BLE Firmware Platform User Guide” (No. 002-11259 Rev. *E), but we might have miss something.

It is possible to reproduce the problem using the BLE Pioneer kit and text commands (configuration details are given below). Note that our product uses the binary protocol and the result is the same.

Here are the instructions to reproduce the problem:

1) Factory reset of the BLE module (bond list has been cleared before)

→ /RFAC

@R,000B,/RFAC,0000

@E,0005,RFAC

@E,003B,BOOT,E=0101011A,S=03030035,P=0103,H=05,C=05,A=00A0504219E3

@E,000E,ASC,S=01,R=03     ← Advertisement is started automatically without whitelist

2) Connection of the smartphone

@E,0035,C,C=04,A=5E972F97FD49,T=01,I=0024,L=0000,O=01F4,B=00

@E,001D,CU,C=04,I=0000,L=0000,O=0000

@E,001D,CU,C=04,I=0000,L=0000,O=0000

@E,001A,W,C=04,H=000B,T=00,D=0200

4) Send pairing request with bond (Re-initialized by the smartphone)

→ /P,M=11,B=01,K=10,P=00

@R,0008,/P,0000

@E,001B,P,C=04,M=12,B=01,K=10,P=00     ← The smartphone send a pairing request, automatically accepted by the BLE module

@E,001D,CU,C=04,I=0000,L=0000,O=0000

@E,000E,ENC,C=04,S=01

@E,001B,B,B=04,A=5E972F97FD49,T=01     ← A bond entry is created

@E,000F,PR,C=04,R=0000     ← Pairing successful

@E,001D,CU,C=04,I=0000,L=0000,O=0000

5) Disconnection and reboot of the BLE module and smartphone Bluetooth

→ /DIS

@R,000A,/DIS,0000

@E,0010,DIS,C=04,R=0916

@E,000E,ASC,S=01,R=03

→ /RBT

@R,000A,/RBT,0000

@E,003B,BOOT,E=0101011A,S=03030035,P=0103,H=05,C=04,A=00A0504219E3

@E,000E,ASC,S=01,R=03

6) Activation of the whitelist for connection (tested with whitelist for connection only and whitelist for both advertisement and connection)

→ /AX     ← Stop advertisement

@R,0009,/AX,0000

@E,000E,ASC,S=00,R=00

→ SAP,M=02,T=00,I=0030,C=07,L=02,O=0000,F=00     ← Set whitelist

@R,0009,SAP,0000

→ /A     ← Start advertisement (also tested with all parameters)

@R,0008,/A,0000

@E,000E,ASC,S=01,R=00

7) Attempts to connect the paired smartphone

Advertisements are received on the smartphone, but when trying to connect, nothing happen!

In the CySmart log file no error. In nRF Connect log file a standard “Error 133 (0x85): GATT ERROR” is listed to inform that the connection failed.

Note: The connection may work if the Bluetooth on the smartphone is not reset. But as soon as the smartphone is restarted or Bluetooth on the smartphone is restarted, the connection is not possible.

😎 Additional verifications

→ GAP

@R,0030,GAP,0000,M=02,T=00,I=0030,C=07,L=02,O=0000,F=00     ← Advertisement parameters and whitelist are OK

→ /QB

@R,000E,/QB,0000,C=01

@E,001B,B,B=04,A=5E972F97FD49,T=01     ← A bond entry exists for the paired smartphone

→ /QWL

@R,000F,/QWL,0000,C=01

@E,0017,WL,A=5E972F97FD49,T=01     ← A whitelist entry exists for the paired smartphone

Configuration details:

* BLE Pioneer Kit (CY8CKIT-042-BLE) + BLE module CYBLE-212019-EVAL

* EZ-Serial version: 1.1.1 downloaded on 06.01.2020 (same version on our product)

* Tested smartphones:

- Samsung Galaxy A70, Android 9

- Sony Xperia XA, Android 7

- iPhone SE, iOS 13.3

* Software used on smartphone for connection and pairing: CySmart, nRF Connect

Other issues:

We also identified other issues related to pairing.

1) Bonds not cleared after factory reset

When the factory reset command is sent we expect that the bonds and white list are cleared. However, the lists persist.

→ /QB     ← Query bonds

@R,000E,/QB,0000,C=01

@E,001B,B,B=04,A=79538A59996E,T=01     ← One bond entry

→ /RFAC     ← Factory reset

@R,000B,/RFAC,0000

@E,0005,RFAC

@E,003B,BOOT,E=0101011A,S=03030035,P=0103,H=05,C=05,A=00A0504219E3

@E,000E,ASC,S=01,R=03

→ /QB     ← Query bond

@R,000E,/QB,0000,C=01

@E,001B,B,B=04,A=79538A59996E,T=01     ← Still one bond entry

2) Delete bond command sometimes doesn’t work

The command for deleting bond entry sometimes fails although advertisement is stopped.

→ /AX     ← Stop advertisement

@R,0009,/AX,0000

@E,000E,ASC,S=00,R=00

→ /QB     ← Query bonds

@R,000E,/QB,0000,C=01

@E,001B,B,B=04,A=5DBAF31F5E73,T=01

→ /BD,A=5DBAF31F5E73,T=01     ← Delete the single bond entry

@R,000E,/BD,0108,C=01     ← Response indicate one remaining bond, Code 0108 “Operation not permitted”

→ /QB     ← Query bonds

@R,000E,/QB,0000,C=01

@E,001B,B,B=04,A=5DBAF31F5E73,T=01     ← No bond deleted

3) Error on pairing response command “smp_send_pairreq_response (/PR, ID=7/5)” when rejected

When the auto-pairing response is disabled, the "smp_send_pairreq_response (/PR, ID=7/5)" command must be sent to accept or reject pairing. Accepting pairing using this command is no problem, but rejecting the pairing result in the error code 0x0104 "Unsupported feature". Using the C-API, the response of the pairing response is ignored by the parser.

→ /AX     ← Stop advertisement

@R,0009,/AX,0000

@E,000E,ASC,S=00,R=00

→ SSBP,M=11,B=1,K=10,P=00,I=3,F=00     ← Disable auto-accept pairing request

@R,000A,SSBP,0000

→ /A     ← Start advertisement

@R,0008,/A,0000

@E,000E,ASC,S=01,R=00

@E,0035,C,C=04,A=5CBDC8BB696D,T=01,I=0024,L=0000,O=01F4,B=00

@E,001D,CU,C=04,I=0000,L=0000,O=0000

@E,001D,CU,C=04,I=0000,L=0000,O=0000

→ /P,M=11,B=01,K=10,P=00     ← Send pairing request

@R,0008,/P,0000

@E,001B,P,C=04,M=12,B=01,K=10,P=00

@E,001D,CU,C=04,I=0000,L=0000,O=0000

→ /PR,C=00,R=0001     ← Send pairing response to reject pairing

@R,0009,/PR,0104     ← Command response with code 0104 “Unsupported feature”

@E,0010,DIS,C=04,R=0913

@E,000E,ASC,S=01,R=03

4) After more than 4 pairing, bond and whitelist entries are managed automatically, but it is undocumented

The documentation supposes that bonds may need to be removed when more than 4 devices are paired. See documentation, page 149, Section 7.2.7.3.

5) Small typo in documentation for “smp_bond_entry”

In “EZ-Serial BLE Firmware Platform User Guide” (No. 002-11259 Rev. *E), page 202, the binary header for the command “smp_bond_entry” mentions a length of 7, but the length is 8.

Thanks for your support,

David

[VenkataD_41]

Hi David,

We reproduced this issue at our side. What we have observed is when the Smart phone's bluetooth is reset sometimes its Resolvable address is changing. We have to add the smart phone's address to resolving list. However, there is no command for Ez-BLE module to add the address to the resolving list. We are looking on workarounds.We guess this might be the reason for the failure of connection.

If you have another PSoC 4 BLE kit, you can confirm this at your side with the attached Central project which advertises with Public address (constant all the time). You can write the address of your Ez-BLE module at the following lines in the project (line 326-331).

Thanks

Ganesh

[DaM__2104136]

Hello,

Thanks for looking at the whitelist/pairing problems.

If the current whitelist is working on static addresses, I understand that it is not effective (since Android 6 and probably iOS 9.3, random addresses are used). As a side note, having no direct control over the list of resolvable addresses in the EZ-Serial API is no problem if it is managed automatically by the EZ-serial app or BLE 4.2 stack.

Also, please note that pairing is working properly, and random address resolution works because a paired device will continue to use bond info after its address changed.

In the last days we implemented a fix based on the fact that pairing and resolving are working (not an EZ-Serial app fix, but an API-client-side fix). This has several disadvantages over whitelist. The principle is the following:

• During the pairing-mode (the mode that is use in most devices to pair it), we request pairing and bonding using smp_pair command when a connection is made.
• In normal mode (outside pairing-mode), we don’t use whitelist and accept any connection.
• When a client device (smartphone) is connected, we wait for a bond entry event (smp_bond_entry) or encryption status change event (smp_encryption_status).
  • If the client device write data (gatts_write_handle) before any bond entry event or encryption status change event, we disconnect it (gap_disconnect).
  • If a bond entry event or encryption status change event has been received, we allow transactions.

The limitations of this fix:

• Scan response are always sent; this does not replace the whitelist on scan request.
• If the client is not paired, it may remain connected if it doesn’t write any data. This block the connection for other clients. We implemented a timeout procedure to limit this.
• An unpaired client can still discover the GATT profiles because no event is generated in the EZ-Serial API for discovery.
• An unpaired client may perform other transactions because we didn’t look at all events that must require pairing.
• This requires more code.

We are looking forward to your fixes and suggestions.

Best,

David

[VenkataD_41]

Hi David,

Thank you very much customer for finding and letting us know the possible issues.

The issue which cannot connect our module after phone Bluetooth off/on is due to the fact that mobile phone uses RPA(Resolve Private Address) but the current PSoC EZ-Serial FW does not support RPA for whitelist.

Thanks and regards

Ganesh