makmorit
commented
6 years ago 原因および対策
１回目のChromeハングについての問題（送信された２件目以降のフレームがnRF52で受信されない）は、BLE接続の問題として、別個に切り分けたいと考えます。
本項では、２回目のU2F Authenticate再失敗についての問題に、スコープを限定するものといたします。
障害時の処理の流れ
One Card側で「INIT frame received again while CONT is expected」と判定するロジック[A]は以下の通り。
【ble_u2f_control_point.c】
void ble_u2f_control_point_receive(ble_gatts_evt_write_t *p_evt_write, ble_u2f_context_t *p_u2f_context)
{
：
NRF_LOG_DEBUG("ble_u2f_control_point_receive length=%u \r\n", control_point_buffer_length);
if (control_point_buffer[0] & 0x80) {
// 先頭データが２回連続で送信された場合はエラー
if ((ble_header_t.CMD & 0x80) && ble_header_t.CONT == true) {
NRF_LOG_ERROR("INIT frame received again while CONT is expected \r\n");
ble_header_t.CMD = U2F_COMMAND_ERROR;
ble_header_t.ERROR = U2F_ERR_INVALID_SEQ;
} else {
// BLEヘッダーとAPDUを初期化
memset(&ble_header_t, 0, sizeof(BLE_HEADER_T));
memset(&apdu_t, 0, sizeof(U2F_APDU_T));
// 先頭パケットに対する処理を行う
u2f_request_receive_leading_packet(
p_u2f_context, &ble_header_t, &apdu_t);
}
：１件目のフレームがCONT frameである旨を設定するロジック[B]は以下の通り。
【ble_u2f_control_point.c】
static bool u2f_request_receive_leading_packet(ble_u2f_context_t *p_u2f_context, BLE_HEADER_T *p_ble_header, U2F_APDU_T *p_apdu)
{
：
// データ（APDUまたはPINGパケット）の長さを取得
p_ble_header->LEN = (uint32_t)(
(control_point_buffer[1] << 8 & 0xFF00)
+ control_point_buffer[2]);
p_ble_header->SEQ = 0xff;
NRF_LOG_DEBUG("INIT frame: CMD(0x%02x) LEN(%d) SEQ(%d) \r\n",
p_ble_header->CMD, p_ble_header->LEN, p_ble_header->SEQ);
：
if (p_ble_header->LEN > BLE_U2F_MAX_RECV_CHAR_LEN - 3) {
// BLEヘッダーに設定されたデータ長が
// 61文字を超える場合、後続データがあると判断
NRF_LOG_DEBUG("u2f_request_receive: CONT frame will receive \r\n");
p_ble_header->CONT = true;
} else {
p_ble_header->CONT = false;
}
：１回目の障害では、
- ロジック[A]により、１件目のフレーム処理において、ble_header_tを0で初期化
- ロジック[B]により、ble_header_t.CONTにtrueが設定
- その後のフレームを受信できなかったため、ble_header_tは別段初期化されず、ble_header_t.CONTはtrueのまま放置
その後発生した２回目の障害で、
- ロジック[A]により、１件目のフレーム処理において、ble_header_t==trueの判定にかかる
- 新規の１件目のフレームとして送信されたにもかかわらず、INIT frameが（１回目の障害時のINIT frameに続いて）２件連続で送信されたと誤判定された
というのが障害時の処理の流れになります。
対策
１件目の障害で、Disconnectされた（＝トランザクションが終了した）にもかかわらず、ble_header_tが初期化されないのが問題のようです。
このような、トランザクションをまたがって使用されることがない変数は、トランザクション開始時（＝Connect時）に初期化する必要があるかと存じます。
具体的には、Connect時に、以下のモジュール変数を初期化（0を設定）させるよう、nRF52側のプログラムを修正しようと考えます。
- control_point_buffer
- control_point_buffer_length
- ble_header_t
- apdu_t
【ble_u2f_control_point.c】
// u2f control point（コマンドバッファ）には、
// 64バイトまで書込み可能とします
static uint8_t control_point_buffer[BLE_U2F_MAX_RECV_CHAR_LEN];
static uint16_t control_point_buffer_length;
// リクエストデータに含まれる
// BLEヘッダー、APDU項目は
// このモジュール内で保持
static BLE_HEADER_T ble_header_t;
static U2F_APDU_T apdu_t;
：
確認された事象
U2FデモサイトでU2F Authenticateを実行したところ、何らかのBLE障害により２つ目のフレーム（CONT frame）が送信されず、エラーが発生しました。 （このとき、Chromeブラウザーはハング状態。ただし、１つ目のフレームが送信されなかった #25 の事象とは異なっています）
ハングしたChromeブラウザーを再起動させ、再度U2F Authenticateを実行しました。
今度は、Chromeブラウザーの子プロセスであるU2F管理ツールから「BLE接続エラーが発生しました。」というエラーメッセージが報告され、再度U2F Authenticateが失敗してしまいました。
ログ
U2F Authenticate１回目の失敗時のnRF52 UARTログ。 １つ目のフレーム（INIT frame）は送信されているが、２つ目以降のフレーム（CONT frame）が送信されませんでした。
U2F Authenticate２回目の失敗時のnRF52 UARTログ Chromeから、フレームは３件送信されていました。 ただし、１つ目のフレーム（INIT frame）が、重複して送信されたと判断されてしまった様子です。 （メッセージ「INIT frame received again while CONT is expected」が出力） その結果、３件のフレーム全てがnRF52ではねられてしまい、結果U2F Authenticateが失敗したようです。