[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無しの場合と有りの場合があるのだ。

• bonding無しのJust Works
• bonding有りのJust Works

無しの場合は、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が来ないと困るので、

4. GAP Paring: Just Works (BLE_GAP_EVT_SEC_PARAMS_REQUEST, AUTH_STATUS)
5. 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