2014/11/02

[nrf51]BLEスタックのイベントハンドラを見る (4)

nRF51 SDKを読んでも理解できなかったので、ネット上にあるNordic社の説明を読むことにしたのだ。
本人としては、よい記事を書いているつもりなのだよ。


BLE_GAP_EVT_SEC_INFO_REQUEST

https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group__nrf51__evt__sec__info__request__encoding.html

処理は、こうなっている。

p_enc_info = &m_auth_status.periph_keys.enc_info;
if (p_enc_info->div == p_ble_evt->evt.gap_evt.params.sec_info_request.div) {
    err_code = sd_ble_gap_sec_info_reply(m_conn_handle, p_enc_info, NULL);
    APP_ERROR_CHECK(err_code);
}
else {
    // No keys found for this device
    err_code = sd_ble_gap_sec_info_reply(m_conn_handle, NULL, NULL);
    APP_ERROR_CHECK(err_code);
}

やっているのはどちらの分岐もsd_ble_gap_sec_info_reply()なのだが、分岐条件がよくわからない。
ハンドラ関数内のstatic変数で、その値はBLE_GAP_EVT_AUTH_STATUSイベント発生時に更新されるのだ。

これについては、先にBLE_GAP_EVT_AUTH_STATUSを見ていった方がよかろう。


BLE_GAP_EVT_AUTH_STATUS

https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group__nrf51__evt__auth__status__encoding.html

パラメータが多いので、並べてみよう。

  • Authentication Status
  • Error Source
  • SM Levels
    • sm1 Level 1
    • sm1 Level 2
    • sm1 Level 3
    • sm2 Level 1
    • sm2 Level 2
    • sm2 Level 3
  • Peripheral Key Exchange
  • Central Key Exchange
  • Encryption Information
  • Identity Resolution Key
  • Address Type
  • Address

いろいろとパラメータはあるのだが、イベント受信時にやっているのはこれだけ。

    case BLE_GAP_EVT_AUTH_STATUS:
        m_auth_status = p_ble_evt->evt.gap_evt.params.auth_status;

Nordicサイトで今まで見てきたバージョンのが検索できなかったが、それほど変わるまい。
https://devzone.nordicsemi.com/documentation/nrf51/6.1.0/s110/html/a00189.html

上記で列挙したパラメータを、ble_gap_evt_auth_status_tで取り扱っているようだ。
自分で設定するわけではないから、Centralから受信した値だと思うのだが・・・。


ようやく、イベントのシーケンス図が見つかった。https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group___b_l_e___g_a_p___s_e_c___m_s_c.html

nRF51 SDK v6に付属のドキュメントは、このシーケンス図が入っていないのだ。
https://devzone.nordicsemi.com/documentation/nrf51/6.1.0/s110/html/a00764.html

mscgenで生成してるような感じはするのだが、SDKのファイルにはそれっぽいのがないので、このシーケンス図は別ファイルなのかもしれない。
v6は失敗時のシーケンスも増えているようなのに、残念だ。

 

見てわかったが、bondingとpairingは微妙に異なるようだ。
同じJust Worksでも、bonding無しの場合と有りの場合があるのだ。

無しの場合は、BLE_GAP_EVT_SEC_PARAMS_REQUESTで「no_bond、no_mitm、no_io_caps」を渡すが、有りの場合は「bond、no_mitm、no_io_caps」を渡すのだ。
イベントのトリガはCentralなので、bondingの有無についてはCentral側の要求次第ということか。
Just Worksの「Just Works」な部分は、no_mitmとno_io_capsで表されているのだろう。

 

今回のBLE_GAP_EVT_SEC_INFO_REQUESTがやってくるタイミングはこちら。
https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group___b_l_e___g_a_p___s_e_c___m_s_c.html

接続までの流れは、この順番だろう。

  1. Advertising
  2. Connection (BLE_GAP_EVT_CONNECTED)
  3. Connection Parameter Update (BLE_GAP_EVT_CONN_PARAM_UPDATE : 設定次第?)

問題は、その次だ。
どのシーケンス図も「Connection Established」で始まっているので、順序がはっきりしない。
実装から見ると、BLE_GAP_EVT_SEC_INFO_REQUESTより先にBLE_GAP_EVT_AUTH_STATUSが来ないと困るので、

  1. GAP Paring: Just Works (BLE_GAP_EVT_SEC_PARAMS_REQUEST, AUTH_STATUS)
  2. GAP Security Establishment (BLE_GAP_EVT_SEC_INFO_REQUEST)

のような流れか。
Just Worksの場合は、SEC_INFO_REQUESTは来ないのかもしれないが、ログを出してみないとよくわからない。

あるいは、先にPeripheral Initiated Security Establishmentなのかもしれんと思ったが、BLE_GAP_EVT_TIMEOUTが発生するにはBLE_GAP_EVT_SEC_PARAMS_REQUESTでタイムアウト値を渡さないといかんのかな?
Core_v4.1.pdf p.2267 「3.4 SMP TIMEOUT」では、タイムアウトは30秒となっているので、そうでもないのかも。
まあ、必要になるまで調べなくてもよさそうだ。


シーケンスが入っている時代のSDKはダウンロードできるようだ。
enumなどの定義値はSoftDeviceとあわせる必要があるので、注意が必要。
http://hiro99ma.blogspot.com/2014/11/nrf51s110-v6nrf51-sdk.html

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。