About saving bonding information

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

cross mob
hinu_4327176
Level 3
Level 3

Hello

After performing (pairing and bonding), if the power is turned from OFF to ON, the key exchange will be performed at the time of connection as if the bonded information was lost.

The following pairing process is implemented.

  ・ Base application: ble_hello_sensor

  ・GATT connection event (GATT_CONNECTION_STATUS_EVT): At connection
           wiced_bt_dev_sec_bond() : Pairing start

  ・Device link key update event (BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT)
           Save link key (wiced_bt_management_evt_data_t paired_device_link_keys_update) to DCT

  ・Device link key request event(BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT)

           Output : saved link key

  ・Power OFF→ON  event(BTM_ENABLED_EVT)
           Set the held link key with wiced_bt_dev_add_device_to_address_resolution_db()

  ・I am using a user passkey when pairing.

  ・Operating environment CYW43438 & WICED-Studio-6.4

If you connect to the central device again after turning the power off and on, the inquiry and key exchange of the user passkey will operate.
I want to connect to the central device once bonded without re-entering the user passkey.

In Windows10 and iOS terminals, user passkey inquiry and key exchange work.

On Android devices, user passkey query and key exchange do not work.

Please tell me how to solve the problem.

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hi Nagao San / hinu_4327176 San,

So I think I understood the issue which customer is telling.

You mean after power off and ON, when connecting to previously connected iphone the passkey entry pop up is again coming ? And you want to avoid that ?

That is because iOS will start the pairing process when it get a pairing request even if the device is bonded.

To avoid that , you can modify the application such that wiced_bt_dev_sec_bond API will be called only if it is not previously bonded device.

Please check the implementation in attached modified project.

Please let me know if this helps the customer.

Regards,
Anjana

View solution in original post

0 Likes
30 Replies
AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

Hi Hiroaki nunome San,

Can you please clarify the query ?

Do you mean for Windows 10 and iOS there device is connecting and pairing is successful without re-entering passkey (after power off & On)

And only for Android , it always asking for passkey entry ?

If that is the case , can you please make sure the device is bonded properly on Android side? Which android app you are using?

Regards,
Anjana

Hello

I'm sorry I don't understand the BT specifications and ask unknown questions.

In the case of Android (using a communication test application as a central), the following operations are performed.
   Connection & pairing start
      ↓
   Passkey request
      ↓
   Pairing completed
      ↓
   Confirm the completion of pairing and bonding with the communication test application
      ↓
   Power off and on CYW43438 (peripheral)
      ↓
   Connection
      ↓
   Connection successful

   "Device link key update event (BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT)" is not issued for connection after power off & on.

In the case of Windows 10 and iOS (using a communication test application as a central), the following operation is performed.
   Connection & pairing start
      ↓
   Passkey request
      ↓
   Pairing completed
      ↓
   Confirm the completion of pairing and bonding with the communication test application
      ↓
   Power off and on CYW43438 (peripheral)
      ↓
   Connection
      ↓
   Passkey request
      ↓
   Pairing completed

   After the power is turned off and on, a "Device link key update event (BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT)" is issued.

   On iOS, the device link key update stops halfway and the pairing fails.

   Since pairing and bonding are completed, passkey request & device link key update event will not occur in connection after power off & on?

The following parameters are set for pairing.
    .oob_data = BTM_OOB_NONE
    .auth_req = BTM_LE_AUTH_REQ_SC_MITM_BOND
    .max_key_size = 0x10
    .init_keys = BTM_LE_KEY_PENC | BTM_LE_KEY_PID
    .resp_keys = BTM_LE_KEY_PENC | BTM_LE_KEY_PID

0 Likes

Hi,

Can you please provide the project which you are testing and steps to reproduce the issue? So that we can figure out the issue.

Regards,
Anjana

Hello

It is difficult to provide everything because of the project during product development.
Provide an excerpted project.

Please wait a little.

0 Likes
lock attach
Attachments are accessible only for community members.

Hello

Attach the part of the project you are testing.

Central uses the application for BLE communication test on iPhone6.
  Application:LightBlue (Downloaded from App Store.)

Reproduction procedure

1) Start Peripheral (apps / BLR_test).

2) The advertisement is send.
      Device name:BLE_test1

3) Select (BLE_test1) from the scan results in Central (LightBlue) and connect.
      Enter the user passkey displayed in the log into Central (LightBlue) and connect.

4) (Bluetooth status events) are issued and pairing works normally.
      event:BTM_PAIRING_IO_CAPABILITIES_BLE_REQUEST_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRING_COMPLETE_EVT

5) Power off and on the Peripheral (apps / BLR_test) and restart.

6) The advertisement is send.
      Device name:BLE_test1

7) Select (BLE_test1) from the scan results in Central (LightBlue) and connect.
      Central(LightBlue):No user passkey request.

😎 (Bluetooth status events) have been issued.
      event:BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT
        ↓
      event:BTM_PAIRING_IO_CAPABILITIES_BLE_REQUEST_EVT)
        ↓ Event publication stops for a while.
      event:BTM_PAIRING_COMPLETE_EVT
        ↓ Pairing will be NG. time out?

In connection 7), the return value of [wiced_bt_dev_sec_bond ()] is [WICED_BT_PENDING].
If bonded, will it be [WICED_BT_SUCCESS]?


If the Pairing IO is set to the following settings, the operation result will change when [Disconnect → Reconnect] with Central (LightBlue).
  (Pairing IO:wiced_bt_dev_ble_io_caps_req_t).local_io_cap = BTM_IO_CAPABILITIES_NONE

4) (Bluetooth status events) are issued and pairing works normally.
      event:BTM_PAIRING_IO_CAPABILITIES_BLE_REQUEST_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
        ↓
      event:BTM_PAIRING_COMPLETE_EVT

5) In Central (LightBlue), [Disconnect → Reconnect].

6) (Bluetooth status events) have been issued.
      event:BTM_PAIRING_IO_CAPABILITIES_BLE_REQUEST_EVT)
        ↓ Event publication stops for a while.
      event:BTM_PAIRING_COMPLETE_EVT
        ↓ Pairing will be NG. time out?

In connection 6), the return value of [wiced_bt_dev_sec_bond ()] is [WICED_BT_PENDING].
If bonded, will it be [WICED_BT_SUCCESS]?


I am confused.
I don't know how to reconnect after pairing and bonding with the iPhone.
Please give me some advice.

0 Likes
lock attach
Attachments are accessible only for community members.

HI Hiroaki nunome San,

I don't see you have saved the paired link keys in BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT.

Can you please save the keys in this event and try ?

Please refer to ble_wifi_introducer demo in SDK for reference.

If you are confused with the event flow during disconnect and reconnect after pairing & bonding, please refer to table under 4B.7 WICED Bluetooth Firmware Architecture in the attached doc for clarification.

Thanks,

Anjana

lock attach
Attachments are accessible only for community members.

Hello

In the source code posted on 1/21, the link key is stored in the following way.

  1)BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
      : Save the link key in a variable.
  2)BTM_PAIRING_COMPLETE_EVT
      :When pairing is completed successfully, save the link key saved in the variable to NVRAM.
       ※The link key last notified by BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT is stored in NVRAM.

Attach the simplified source code.
The same phenomenon as the source code posted on 1/21 occurs.

[Outline of processing]
  1)GATT_CONNECTION_STATUS_EVT
      : Execute wiced_bt_dev_sec_bond () when connected.

  2)BTM_PAIRING_IO_CAPABILITIES_BLE_REQUEST_EVT
      : Set pairing_io_capabilities_ble_request

  3)BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT
      : Save paired_device_link_keys_update to NVRAM.
        Save to DCT_APP_SECTION with wiced_dct_write ()
        ※ble_wifi_introducer/ Saving paired_device_link_keys_request.
          Judged that the method of retaining paired_device_link_keys_update is correct.

  4)BTM_ENABLED_EVT
      : Set the link key saved in NVRAM with wiced_bt_dev_add_device_to_address_resolution_db()

  5)BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT
      : Set the link key saved in NVRAM to paired_device_link_keys_request

  6)BTM_SECURITY_REQUEST_EVT
      : Execute wiced_bt_ble_security_grant()


  The source code posted on 1/21 is also implemented with reference to ble_wifi_introducer.
  Are there any other events that need to be processed?

Thanks

0 Likes

Hello

Did you reproduce this problem with the project you provided?

As a hint to solve the problem, is there a sample program that has a track record of operation other than [ble_wifi_introducer /]?

1)Pairing & bonding
2)Power OFF⇒ON & reconnect to bonded device

Thanks

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

Hi Hinu-san,

>BLE_test.zip

This simple reproduction project seems to have additional debug logs.

Could you attach a log for reproducing the issue for analysis?

Thanks

0 Likes
lock attach
Attachments are accessible only for community members.

Hello

Attach a log of when the problem was reproduced.

It will be helpful if you can give us advice that can solve the problem

Thanks

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

February 28, 2020 8:46 PM

E-mail To hinu_4327176 from HiNa_2357246

-----

ログで気になる点は以下です。

[2020-02-28 15:16:57.594] !!!!!!!!!!!!!!!!!!!!!!!!!! management event 21

これは,

BTM_LOCAL_IDENTITY_KEYS_REQUEST_EVT

になりますが, ble_ctrl.c では,

result = WICED_BT_NO_RESOURCES;

を返すだけのコードになっています。

これは,自分の鍵情報を持っていないということを示しますので,

これを受け取った BT スタックは,新規で鍵を生成します。

初回は,このコードで良いと思いますが,2 回目以降は,以前の

鍵を使用する必要があるかと思います。この鍵を変えてしまうと,

正常に通信できずに新規の扱いになってしまう可能性があります。

実際に,

[2020-02-28 15:15:33.490] !!!!!!!!!!!!!!!!!!!!!!!!!! management event 20

のところで,

BTM_LOCAL_IDENTITY_KEYS_UPDATE_EVT

のイベントが通知されていますが, NV RAM に保存するような

コードも書かれていないようですので,この部分も対応する

必要があるかと思います。

具体的には,

------------------

UPDATE_EVT では,

p_event_data->local_identity_keys_update

を NVRAM に保存する。

REQUEST_EVT では,

NVRAM にデータがあれば,それを読み出し

p_event_data->local_identity_keys_request

に格納して WICED_BT_SUCCESS を result として返す。

データが無ければ,今のまま。(WICED_BT_SUCCESS 以外を result

として返す)。

------------------

という処理を追加して,動作を見て頂けますでしょうか。

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

Hi Anjana-san,

I received an urgent question from customer.

Please check the following.

-Did the issue reappear at your desk with the sample source code attached with Reply 5?

  Please tell us the current analysis status.

-Customer requires a sample program that works correctly for this issue. Is it possible to provide samples?

  If possible, is it possible to release by end of this week?

Regards,

Nagao.

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

March 3, 2020 10:24 AM

E-mail To hinu_4327176 from HiNa_2357246

改善は見られなかったとのこと、承知いたしました。

お手数ですが下記のメールで頂いているサイプレス社へのリクエスト等は

Community上でも同じ内容でリクエスト頂く様お願いします。

以下、Communityへ添付されているソースコードの確認結果です。

ソースコードを見ると,Cypressの評価ボードではなく,

独自のボード(platform/TEST_board)に合わせた設定になっているようです。

サイプレス社には貴社ボードがございませんので、Cypressの評価ボード上で

再現できる環境としなければボード環境の合わせこみにかなりの工数が割かれる可能性があります。

解析を進めるために,追加でお願いがあります。

  1. 1. Air sniffer でのログ取得

    Frontline 社や Ellisys 社での Air Sniffer が使えるようであれば,ログの取得をお願いいたし

    ます。この情報が分かると,解析が加速します。

  1. 2. 対抗機の Snoop 情報

    対抗機側で HCI Snoop ログの取得はできませんでしょうか。少なくとも,少し前の Android スマホ

    では,「設定」「開発者オプション」の下でHCI snoop ログの ON/OFF が設定でき, ON に

    した場合には, SDCARD に保存されると思います。

  1. 3. 今回,お願いしていた変更を行ったときのソースとログ

    期待した動作をしているのかを見たいと思いますのでソースとログをお願いいたします。

UPDATE と REQUEST でやり取りしているデータの内容がログに出ていると確実に制御できているかを

    確認できると思います。

  1. 4. 一部,ソースコードの変更

    CDC には,ソースが 2 種類上がっていますが,

    そのうちの一方には,好ましくない設定になる恐れのあるコードがあります。

BLEctrl_pairing_io_capabilities_ble_request_evt()

    で, local_io_cap に BTM_IO_CAPABILITIES_NONE

    が設定される場合がありますが,この設定では

    auth_req = BTM_LE_AUTH_REQ_SC_MITM_BOND は

    使用できません。 MITM の設定を外してください。

お手数ですが下記のメールで頂いているサイプレス社へのリクエスト等は

Community上でも同じ内容でリクエスト頂く様お願いします。

0 Likes

Hello

1. What is the status of the analysis of malfunctions and how to handle them?

    Did the problem Reproduce in the source code submitted on February 20?

    If reproduced, what is the status of the cause analysis?

    When is the proposal for the countermeasures?

2. The submission of operable sample software requested on February 25 should be received on March 4.

Thanks

0 Likes
lock attach
Attachments are accessible only for community members.

> 1.1. Air sniffer でのログ取得

 I tried to get it with wire shark, but the sniffer wasn't stable and logs weren't getting well.

 confirm one more time

> 1.2. 対抗機の Snoop 情報

 We will send logs. please confirm.

 (Document:HCI_Log.zip)

> 1.3. 今回,お願いしていた変更を行ったときのソースとログ

 We will send source and log. please confirm.

 (Document:source&log.zip)

> 1.4. 一部,ソースコードの変更

 In the current source, "BTM_IO_CAPABILITIES_NONE" is not specified, so there is no correspondence.

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

snoop ログを確認しました。

現象が発生したのは 16:15 ごろの物でしょうか?

(teraterm のログから判断しています)。

その時間に相当する snoop のログがありません。

snoop の方が 1 分程度早いのでしょうか?

可能であれば,時計を合わせて頂けませんでしょうか?

もし,現時点でログ取得時のずれが分かるようであればお知らせください。

もし,分からないのであれば,時刻を合わせた後,ログの取得をお願いいたします。

動作させたときの状況をお知らせ頂けませんでしょうか。

teraterm ログの方はリアルタイムに確認できると

思いますので,例えば

-----

[2020-03-03 16:14:24.299] DUT 起動,この時点では鍵なし

[2020-03-03 XX:XX:XX.XXX] 対抗機から接続

[2020-03-03 XX:XX:XX.XXX] 対抗機から Pairing 開始 正常

[2020-03-03 XX:XX:XX.XXX] 対抗機から切断

[2020-03-03 XX:XX:XX.XXX] DUT 電源断

[2020-03-03 XX:XX:XX.XXX] DUT 起動

[2020-03-03 XX:XX:XX.XXX] 対抗機から接続

[2020-03-03 XX:XX:XX.XXX] 対抗機から Pairing 開始 これを無くしたい

-----

というような形で情報を頂けると,解析を効率的に

進めることが可能になります。

0 Likes
lock attach
Attachments are accessible only for community members.

> その時間に相当する snoop のログがありません。

> snoop の方が 1 分程度早いのでしょうか?

> 可能であれば,時計を合わせて頂けませんでしょうか?

>

> もし,現時点でログ取得時のずれが分かるようであればお知らせください。

> もし,分からないのであれば,時刻を合わせた後,ログの取得をお願いいたします。

  There seems to be no time lag for both smartphones and PCs.

  (NICT time check: PC: 0.1 seconds, smartphone: 1.4 seconds delay)

> 2.動作させたときの状況をお知らせ頂けませんでしょうか。

  The log was output in detail and the log was acquired again. The status at the time of operation was described in the log.

  The operation procedure is described in Readme.txt, so please refer to it.

  (Document:No129_20200304.zip)

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

現在弊社で解析を進めておりますが、

下記に詳細を記載しますが、問題がどこにあるのか不明瞭な状況となってきました。

そのためサイプレス社で再現できたかどうかに関しても、

大変申し訳ないのですが、現時点では非再現かつ修正時期も未定となっております。

この数日間に頂いた情報を踏まえて改めてCommunity の当初の問い合わせ内容を

確認させて頂きました。

> If you connect to the central device again after turning the power off and on, the inquiry and key exchange of the user passkey will operate.

とのことですが、

「電源 OFF/ON した後, Central とすると, Inquiry と User passkeyの交換が実施される。」

これを改善(変更?)したいと読み取れます。

しかし今回の場合,1回目は相手が鍵を消したので,

Bluetooth の仕様上必要なのでPairing の処理が走っていますが,

2回目はすぐに暗号化の処理が動き出していますので,期待通りの動作をしているように見えます。

この動作は全く問題なく、このタイミングで大変申し訳ないのですが

再度問題点と期待動作を明示頂けますでしょうか?

0 Likes

Hi hinu_4327176 ,

I am sorry for the delay in response. I couldn't able to get back to you because of some other work.

I tested the project attached in the Reply 5 (attached on 20-Feb-2020 ). I don't see any issue with the implementation.

Its working fine as expected. I tested with CySmart mobile app in Android phone .

I don't know what you are thinking as issue in that project. Please let me know.

Below is the expected behavior and is working as the same in the project which you shared on Feb 20.

1. on the first connection , passkey request will come . You need to enter passkey. pairing will be success . BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT event will get triggered and you have to save the link keys to NVRAM = > this is happening in your project

2. disconnect and connect immediately after connection  - this time neither BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT  or BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT will not get triggered . Only BTM_ENCRYPTION_STATUS_EVT event will get triggered. As the device is already paired , you won't get the passkey entry again.

3. Reset / power off and on CY4343x device and connect to bonded device - this time only BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT  event will get trigger and you should compare the bonded info and can check bonding info is present or not. BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT  event will not be triggered on this condition. Since the device is found already bonded , there won't be a passkey entry again.

For the detailed explanation of flow of these events I would suggest you to please go through the doc which I shared previously. WBT101-04B-BLE-Ntfy-Sec.pdf  please refer to table under 4B.7 WICED Bluetooth Firmware Architecture ...

Now let me explain corner case tests :

case 1. Now both the devices are in paired and bonded . At this stage if you reprogram your 4343 chip, the bonding info will be lost as reprogram will rewrite the nvram. But in your mobile phone the device info is stored. You haven't removed / forget the device yet. In this state if you are trying to reconnect to newly programmed 4343 chip, pairing will fail. This is as per spec. This is because mobile (Central ) have the bond info and 4343 (peripheral ) doesn't have bond info which will be a mismatch and Central can initiate a disconnect request because of pairing failure.

case 2. Now consider the opposite way.

You are in state where both 4343 and mobile is paired and bonded. At this stage if you forget the device (removing bond info) from mobile (Central) , but you have not removed or reprogrammed the bond info from 4343x (peripheral ) . In this state there may not be a disconnection, rather the pairing will re-initate by passkey request so that Central can save the bond info again.

case 3. In the current example which you shared for testing, you are considering saving the bond info only for one device . This means if you connect to a new central (another mobile phone other than previously connected) . When you connect to new device it will pair and bond to new device and erase the previous bonded info as you have not handled the project for multiple device bonding. So after bonding to a second device and reconnecting to first device (to a mobile which still saves the bond info of 4343) , this will result in case 1 which we discussed and may end up in disconnection. If your application requires multiple device bonding, let us know we can suggest the usage.

Hope this clears your doubts. Please let us know if you need clarification. Please kindly go through the doc WBT101-04B-BLE-Ntfy-Sec.pdf  please refer to table under 4B.7 WICED Bluetooth Firmware Architecture ...

Note: The doc is part of our WICED ACADEMY for 20xx based BT chips available here: GitHub - cypresssemiconductorco/CypressAcademy_WBT101_Files: Files for WICED Bluetooth 101 class 

Though the Academy talks about BT chips (not combo chips) , the details almost remain same.

Also you can refer to another example for security on Bt chip here: CYW20706 – BLE Secure Data Hub

Thanks & Regards,

Anjana

HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

Response from customer

> DUT からセキュリティ要求をした後 Pairing を開始したのは対抗機側のようですので

> 対抗機側を調べた方が良いかもしれません。

 ->今回の問題としている対抗機は、iPhone(iOS)となります。

 Androidは、今回は問題としていませんので、主旨が異なると思われます。

 ※展開しているログはAndroidのログとなります

> もし,正しい鍵があり,十分なセキュリティレベルを

> 持っていれば,pairing せずに暗号化を開始するだけ

> のはずです,ここで pairing が走るということは,

> 鍵を保存していないか,セキュリティレベルが低いと

> 判断されたのではないでしょうか?

 ->鍵を保存しているが、保存されていない動作になっていることが問題だと思っております。

 「ble_ctrl.c」のwiced_bt_dev_add_device_to_address_resolution_db関数で

 リンクキーを設定しているが、鍵として認識していないと思われます。

   ⇒ログで、「BTM_ENABLED_EVT link key set!」と表示されている箇所になります

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

Hi Anjana-san,

Thanks for your analysis and comments.

I confirmed with the customer about the snoop log.

Android snoop log was attached, but this log is Success case.

Customer said that issue occur when the peer device is an iphone.

So, I asked customer for an iphone log (airlog).

Regards,

Nagao.

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

BLE は用途ごとに複数の鍵があり,

     address_resolution で使用する鍵は IRK

     暗号化で使用する鍵は LTK

です。他にも鍵はあります。(詳細は SIG の仕様書を参照してください)。

wiced_bt_dev_add_device_to_address_resolution_db() で設定するのは

RPA(Resolvable Private Address) 用の address resolution database

になりますので,IRK のみとなります。そのため,暗号化時には追加で

鍵情報(LTK)が要求されること自身は問題ありません。期待通りの動作となります。

IRK は,相手の機器が何者であるかを判断するためのもの(アドレス情報)

になりますので,接続前の時点でも必要になります。そのため,先に登録

する必要があり,専用の API が用意されています。

LTK 等の鍵は,接続後に用意しても十分,間に合いますので,

BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT で渡すという API になります。

ここまでで基本的に問題ないという認識ですが,まだ動作がおかしいようであれば以下の対応をお願いいたします。

ソースコードをレビューしていて少し気になった点になります。

hinu_4327176 27-Feb-2020 22:30 (in response to HiNa_2357246)

鍵の種類はログに出ていませんが,4回,通知されています。

[2020-02-28 15:16:12.678] !!!!!!!!!!!!!!!!!!!!!!!!!! management event 18

[2020-02-28 15:16:12.975] !!!!!!!!!!!!!!!!!!!!!!!!!! management event 18

[2020-02-28 15:16:13.240] !!!!!!!!!!!!!!!!!!!!!!!!!! management event 18

[2020-02-28 15:16:13.522] !!!!!!!!!!!!!!!!!!!!!!!!!! management event 18

BLE_test のソースのソースでは,

hinu_4327176 20-Feb-2020 03:02 (in response to AnjanaM_61)

     case BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT:

         memcpy(&stPeriInfo.stLnkKey,

             &p_event_data->paired_device_link_keys_update,

sizeof(wiced_bt_device_link_keys_t));

         wiced_dct_write(&stPeriInfo, DCT_APP_SECTION, 0,

             sizeof(st_ble_pair_t));

とあり,通知された鍵が上書きされていくようです。

まずは,この部分で

p_event_data->paired_device_link_keys_update

     .key_data.le_keys_available_mask

を表示するようにしてみて頂けますでしょうか?

それぞれの通知で,鍵タイプ(enum wiced_bt_dev_le_key_type_e)が変わっていくと思います。

これらが, OR で追加されていく形であれば,単純に上書きで問題ありませんが,

個別に通知される場合には,必要な鍵だけを更新していく必要があるかと思います。

もし,挙動がおかしいというのであれば,念のためこの部分を確認すると良いかと思います。

また,現象が発生したときの Airログと teraterm ログのセットをお送りいただければ調査いたします。

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Nagao San / hinu_4327176 San,

So I think I understood the issue which customer is telling.

You mean after power off and ON, when connecting to previously connected iphone the passkey entry pop up is again coming ? And you want to avoid that ?

That is because iOS will start the pairing process when it get a pairing request even if the device is bonded.

To avoid that , you can modify the application such that wiced_bt_dev_sec_bond API will be called only if it is not previously bonded device.

Please check the implementation in attached modified project.

Please let me know if this helps the customer.

Regards,
Anjana

0 Likes

Thank you for developing the sample code(BLE_test.zip).

Please answer the following questions as there are unclear points in the sample code

・I ask a question because I want to understand the processing.

  The registration status of the bonding information is used to determine whether to register.

  Why is this improved?

・The BLE address is used to determine whether bonding can be set, but the iphone seems to change its BLE address.

  Is the operation correct even if the BLE address changes?

  If correct, please tell us why.

・If there is a problem with the above answer, isn't it possible to use an immutable value such as a smartphone-specific UUID?

0 Likes
HiNa_2357246
Level 5
Level 5
Distributor - Macnica (Japan)
5 likes given 50 replies posted First like given

Hi hinu_4327176

Could you answer the question from Cypress?

>You mean after power off and ON, when connecting to previously connected iphone the passkey entry pop up is again coming ? And you want to avoid that ?

Also, does the test program(BLE_test.zip) operate as expected? Or do we need further fixes?

Regards,

Nagao.

0 Likes

> You mean after power off and ON, when connecting to previously connected iphone the passkey entry pop up is again coming ?

  Passkey entry pops up again.

> And you want to avoid that ?

  Yes, I want to avoid.

> Also, does the test program(BLE_test.zip) operate as expected? Or do we need further fixes?

  I am still checking, but I think peripheral is working.

  For Central, we are checking.

  Correction is required depending on the verification result.

0 Likes

Hi ,

Please note in this thread I tested and gave the solution only for peripheral role.

For the issue reported for 4343x as Central side , How to specify your own user passkey is different. For Central role, with io capability keyboard there is a known pairing failure issue reported in the other thread. And the issue is only in SDK 6.4 and not in SDK 6.2 .

As you can't move to 6.2, I have escalated this issue internally or please contact your FAE.

If you are using any other io capability other than keyboard, then this issue is not there.

Thanks,
Anjana

0 Likes

Hi hiko_4316286 ,

Q) I ask a question because I want to understand the processing.

  The registration status of the bonding information is used to determine whether to register.

  Why is this improved?

A) I am sorry, I couldn't able to understand the query

Q)The BLE address is used to determine whether bonding can be set, but the iphone seems to change its BLE address.

  Is the operation correct even if the BLE address changes?

  If correct, please tell us why.

A) Yes iphone / android phone will be using RPA and may change the address mostly after power off and on. But since we are adding the address to resolution dB. (wiced_bt_dev_add_device_to_address_resolution_db) , the address can be resolved and detect the public address associated. So that device won't treat the phone as new device.

You can confirm this by testing the same project with and without wiced_bt_dev_add_device_to_address_resolution_db.

 

Regards,
Anjana

Hi AnjanaM_61,

> Q) I ask a question because I want to understand the processing.

>  The registration status of the bonding information is used to determine whether to register.

>  Why is this improved?

>A) I am sorry, I couldn't able to understand the query

  I reviewed the sentence.

  The problem of bonding was improved by the modification of the sample code (BLE_test.zip), but I do not understand why it was improved.

  Can you explain the change because I want to understand what's going on?

Regards,

Komuro.

0 Likes

Hi hiko_4316286 ,

Q) The problem of bonding was improved by the modification of the sample code (BLE_test.zip), but I do not understand why it was improved.

A)

If the device is already bonded, then you there is no need to start the pairing process adain.  iOS will start the pairing process when it get a pairing request even if the device is bonded. To avoid that , I modify the application such that wiced_bt_dev_sec_bond API will be called only if it is not previously bonded device.

Regards,
Anjana