[wsh]JScriptはShift-JIS + CR/LFっぽい

Windows上でJavaScriptを動かすときは、どうやらJScriptと呼ぶらしい。
JavaScriptともちょっと違った書き方ができるというか、何かルールがあるようだ。

ファイルを読んで、置換して、別ファイルに書き込む、というものを書いてみた。

var inFile = "test.html";
var outFile = inFile + ".html";
//読込み
var inStream = new ActiveXObject("ADODB.Stream");
inStream.Type = 2;      //text
inStream.charset = "utf-8";
inStream.Open();
inStream.LoadFromFile(inFile);
var inText = inStream.ReadText(-1);       /* -1:全部 -2:1行ごと */
inStream.Close();
//置換
inText = inText.replace(/<value1>/g, "-1");
inText = inText.replace(/<value2>/g, "abc");
inText = inText.replace(/もういやだ/g, "");
WScript.Echo(inText);
//console.log(inText);
//書き込み
var outStream = new ActiveXObject("ADODB.Stream");
outStream.Type = 2;
outStream.charset = "utf-8";
outStream.Open();
outStream.WriteText(inText, 1);    /* 0:改行無し 1:改行有り */
outStream.SaveToFile(outFile, 2);  /* 1:なければ新規作成 2:新規作成かつ存在すれば上書き */
outStream.Close();

読み込むファイルは、これ。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8" />
    <title>Hello</title>
</head>
<body>
    <script language="JavaScript">
        var foo = <value1>;
        document.write("寒い<value2>。");
        もういやだ
    </script>
    Hello World!
</body>
</html>

<value1>に「-1」を、<value2>に「abc」を、「もういやだ」を空行にしたい。
「もういやだ」は行ごと削除したいけど、まあHTMLだからいいだろう。

これを実行したのだが・・・。
結果がこれ。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8" />
    <title>Hello</title>
</head>
<body>
    <script language="JavaScript">
        var foo = <value1>;
        document.write("寒いabc。");
        もういやだ
    </script>
    Hello World!
</body>
</html>

中途半端に<value2>だけ置換されている。
よくわからんので、jsの方で<value1>と<value2>の順番を入れ替えた。
そうすると、<value1>が置換された。

ここら辺で、Windowsだから、ということに気付いた。
文字だけではわからないところだが、HTMLファイルはUTF-8/LF、JSファイルもUTF-8/LFで保存している。
やっぱりCR/LFじゃないとわからないってことか？ということで、JSファイルをUTF-8/CRLFにした。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8" />
    <title>Hello</title>
</head>
<body>
    <script language="JavaScript">
        var foo = -1;
        document.write("寒いabc。");
        もういやだ
    </script>
    Hello World!
</body>
</html>

<value1>と<value2>は置換された。
そして日本語が残った。。。
ということは、Shift-JISじゃないとだめなのか？ということで、JSファイルをShift-JIS/CRLFで保存。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8" />
    <title>Hello</title>
</head>
<body>
    <script language="JavaScript">
        var foo = -1;
        document.write("寒いabc。");
        
    </script>
    Hello World!
</body>
</html>

はー、そういうことなんですな。

結論としては、こう。

WindowsのJScriptは、Shift-JIS + CR/LFで保存しよう

 

ちなみに、このJSをそのまま動かすと、出力したファイルの最後にCR/LFの改行が入る。
「ちっ」と思っていたが、WriteText()で改行有りにしていたからだった・・・。

[wsh]JScriptでUTF-8ファイルを読んで置換して保存

今のお仕事の、作業環境にいろいろと制約がありましてな・・・。
簡単な作業をしたくても、パズル的に制約をかいくぐる必要がありまして。

今回やりたいのは、こんなこと。

• Windows環境
• ファイルを読み込んで、置換して出力したい
• 文字コードは、UTF-8 / LF
• 出力したファイルを別コマンドに喰わせたいので、スクリプト1発で済ませたい
• Windowsの素の環境で動くこと＋ダウンロードをまったく使わないこと

sedとかperlとかあれば済む話なんだけど、ネットを使えないので入っていない。
いや、頼めばやってくれそうではあるけれども、頼むのがめんどくさいし、少しくらい障壁があった方が燃えるじゃないか。
そもそも、この課題自体が自分で立てたようなものだし。

ネットで検索して、こんなコードができた。
ここに書いてもダウンロードできないけど、見ながら入力するのはよいだろう。

var inFile = "in.txt";
var outFile = "out.txt";
var inStream = new ActiveXObject("ADODB.Stream");
inStream.Type = 2;      //text
inStream.charset = "utf-8";
inStream.Open();
inStream.LoadFromFile(inFile);
var inText = inStream.ReadText(-1);       //-1:全部 -2:1行ごと
inStream.Close();
inText = inText.replace(/100/g, "-1");
inText = inText.replace(/ABC/g, "abc");
var outStream = new ActiveXObject("ADODB.Stream");
outStream.Type = 2;
outStream.charset = "utf-8";
outStream.Open();
outStream.WriteText(inText, 1);    //0:改行無し 1:改行有り
outStream.SaveToFile(outFile, 2);   //1:なければ新規作成 2:新規作成かつ存在すれば上書き
outStream.Close();

最後のSaveToFile()には、ドキュメントにだまされた。
詳細はこちらをご確認くだされ。

あと、replace()の第1引数も想定と違っていた。
最初は"/100/g"のような文字列で書いてたんだけど、ダブルクオーテーションとかで囲むとダメなんだな。
理屈はわからんが、/で囲むのが正規表現値、みたいな意味なのかな。

[rpi]Android端末をAccessory Modeにしてみよう

前回Raspberry Piにシリアルをつけたけど、SSHが使えるんだったらそっち経由でよいことに気付いた。
どこら辺の問題かわからないけど、シリアルを取りこぼしているような感じがするのだ。
ばたばた出力が流れていると、いつの間にか1文字分が遅れているような感じだ。
TeraTermからリセットを通知するとうまくいくし、そうでなくても「遅れる」という現象なので、データとしては届いていると思うのだ。
んー、なんだろう？

 

それは忘れて、Raspberry PiとNexus5を接続して、Nexus5をAccessory Modeにしてみよう。
Accessory Modeというのは、USB Host機能を持つ端末にAndroid端末を接続し、データを通信し合うモードだ。
標準？といってよいかわからないが、Arduino MEGA ADKが一般的によく使われるようだ。
Arduino UnoなどにUSB Hostのドータボードを載せればよいとも聞いた。

---

理屈はそんなに難しいものではなく、USB接続して、Accessory Modeになる手順を通信すればよい。

ドライバを作るとよいのだろうが、あまり手間はかけずにアプリだけで実装した。
libusb 1.0でNexus5のVID/PIDを検索してオープンし、libusb_control_transfer()でACCESSORY_GET_PROTOCOLを送信してNexus5がAccessory Modeをサポートしていることを確認し、ベンダ名、モデル名、ディスクリプション、バージョン、URI、シリアル番号を送信し、最後にACCESSORY_STARTを送信。

そうすると、Nexus5に対応したアプリが入っていないためかURI先に飛ぶ確認画面が出てきた。
Androidアプリはまだ作っていないのだが、セミナーでやった様子からすると、対応したアプリがあればこのタイミングで起動することだろう。

上で出てきたACCESSORY_STARTなどは、f_accessory.hというヘッダファイルに定義してある。
これがどこから持ってきたのか・・・。
gitには入っているようなので、AOSPから落としてくるか、少なくともkernel-headersだけでもcloneすればよいのではなかろうか。

 

むかーし、この辺りは調べていたようだが、もう3年半くらい前になるため記憶がほとんどない。。
BeagleBoardにAOSPであれこれ試しながら進めていたようで、プロトコルを訳しながら調べたドキュメントもあった。
やるなあ、当時の私。

[pi]シリアルケーブルをつなぐ

ひさーしぶりに、Raspberry Piに火を入れた。
たまには違うことしないと、頭が固まりそうだからね。

---

シリアルケーブルは、スイッチサイエンスさんから購入していたものを使う。
http://www.switch-science.com/catalog/1196/

レベルコンバータとか使うのが面倒なので、3.3Vで使えるケーブルがあるから買っていたのだ。
ここで使うとは思ってなかった。

思ってなかったが、上記ページに行くと、Raspberry Piへの接続が載っていた。
なんか、先回りされた気分だ・・・。

このケーブルはUSBから電源を供給しているので、microUSBケーブルがなくてもONできるのがありがたい。

最初、buildrootか何か忘れたけど、自分でビルドしたシステムで起動させていたのだが、シリアルには何も出てこなかった。
オリジナルのRaspberianにすると、出てきた。

LANケーブルをつなげばpingも通ったので、HDMIで画面出さなくてもなんとかなりそうだ。
グラフィックを使う予定がないときは、コンソールの方が楽なのよねぇ。

[ble]nRF51822の開発環境を思い出す(2014/11/02現在)

[ble]nRF51822の開発環境を思い出す(2014/09/17現在)

前回から1ヶ月半くらい経ったが、それなりに経験値が上がったように思う。
メモとして残しておこう。

---

Keil v5を試した。

• [nrf51]Keilを使ってみる

さすがというか、使いやすいと感じた。
今はgcc環境ができあがっているから使わないけど、仕事でやるならこれだろう。

---

スケジューラについて調べた。

• [nrf51]スケジューラは結局なんなんだ？ - (1)
• [nrf51]スケジューラは結局なんなんだ？ - (2)

今のところ、割込コンテキストで動作する時間を短くするためのもの、という解釈をした。

---

試しに、サービスを含めて一式作ってみた。
といっても、サンプルを改造しただけだが。

[nrf51]はじめてのBLEアプリ - (1)サービスをつくる

[nrf51]はじめてのBLEアプリ - (2)アプリを作る

[nrf51]はじめてのBLEアプリ - (3)デバッグ

サービスについてはドキュメントもあったため比較的やりやすかったが、アプリ部分はよくわからないまま流用している。

---

わからんままじゃだめだろう、ということで、BLEイベントハンドラを調査した。

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

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

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

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

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

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

nRF51 SDK v4のドキュメントであればシーケンスが載っていることがわかったのが、一番の収穫だった。

---

こんなところか。
まあ、がんばってるんじゃないかね、うむ。

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

サンプルソースのBLEイベントハンドラの調べ物。
最後の１つだ。

---

BLE_GATTS_EVT_SYS_ATTR_MISSING

前回まではGAPのイベントだったが、これはGATT Serverのイベントだ。

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

Disconnectされたとき、SoftDeviceにsystem attributeデータを取得して保持しておき、次に接続するときに再設定するしくみのようだ。

BLE_GATTS_EVT_SYS_ATTR_MISSINGの説明としては、sd_ble_gatts_sys_attr_set()待ち、らしい。
確かにイベントハンドラでも、sd_ble_gatts_sys_attr_set()を呼び出している。
"persistent system attribute"というのは、BLEスタックが返す値のようで、アプリはそのコピーを持っておき、この関数で渡すようなしくみらしい。
コピーじゃなくてNULLを渡すと、前回の値はないよ、ということで初期化されるようだ。
storageという単語が出てくるから、保持しておきたいデータ、みたいな使い方なのか。

サンプルではNULLを渡すだけになっている。

---

似たような感じで、Notify投げようとしてエラーで帰ってくる場合もあるようだ。

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

sd_ble_gatts_hvx()を呼んで、エラーが発生した場合のようだ。
まずsd_ble_gatts_hvx()はNotifyを投げるときに使っている。
サンプルでは、このエラーが発生すると、単にエラーという扱いにしている。

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

nRF51 SDKを読んでも理解できなかったので、あれこれ読みながら調べている。

---

BLE_GAP_EVT_TIMEOUT

サンプルにあるGAPイベントの最後が、これ。
https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group__nrf51__evt__timeout__encoding.html

サンプルではAdvertisementでタイムアウトした場合の処理だけしてある。
取り得る値は、以下。

• BLE_GAP_TIMEOUT_SRC_ADVERTISEMENT
• BLE_GAP_TIMEOUT_SRC_SECURITY_REQUEST

Advertisingのタイムアウト時間は、sd_ble_gap_adv_start()で設定している。
Security Requestの方は、sd_ble_gap_sec_params_reply()か、30秒(Core_v4.1 Vol.3 Part.H "3.4 SMP TIMEOUT")だと思う。

ビーコン端末だとAdvertisingでタイムアウトしたら困るよな、とble_app_beaconサンプルを見ると、0で指定されていた。

[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

[nrf51]S110 v6系に対応したnRF51 SDKはダウンロードできない？

古いバージョンのSDKは、ここからダウンロードできるようだ。
https://www.nordicsemi.com/eng/nordic/Products/nRF51822/nRF51-SDK-zip/23446

v6.0.0の前は、v4.4.2になるのだな。
その間のv5系はどういう扱いなんだろう？

前回、nRF51822に焼かれていたSoftDeviceバージョンと、ビルドに使っていたSDKバージョンが不一致だったためにはまったので、バージョンのことは意識しておきたい。

こう書いてあるので、nRF51 SDK v6.1.0はSoftDevice S110 v7.0.0(今はv7.1.0か)用なのだろう。

その前は記憶があやふやなのだが、nRF51822にv5系のSoftDeviceがインストールされていて、nRF51 SDKがv5系だったようだ。
SDKのリリースノートを見ると、SDK v5.2.0はS110 6.0.0対応となっている。
で、SDK v4.4.2はS110 v5.2.1らしい。

なので、

SoftDeviceのメジャーバージョン＝SDKのメージャーバージョン＋１

という関係なのか。

 

ならば、SoftDevice v6系の人はSDK v5系がいるはずなのだけど、nrf51_sdk_v5_2_0がリストにないので、もはやダウンロードできないのではなかろうか。
でも、SoftDevice v6はまだダウンロードできるようだし。
うーむ。。。

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

nRF51 SDKを読んでも理解できなかったので、ネット上にあるNordic社の説明を読むことにした。
ゆっくりだ、ゆっくりとやろう。

---

BLE_GAP_EVT_SEC_PARAMS_REQUEST

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

いきなりフレームフォーマットがどうのこうのと書かれているが・・・何もわからん。
BLEの通信プロトコルのどこかだろうと検索するが、それっぽいものが見つからない。

セキュリティから始めるのは、敷居が高かったか。

---

ソースでやっていることは、これ。

err_code = sd_ble_gap_sec_params_reply(m_conn_handle,
                                       BLE_GAP_SEC_STATUS_SUCCESS,
                                       &m_sec_params);

m_sec_paramsの内容を渡しているだけのようだ。
このパラメータは、あらかじめ設定している。

    m_sec_params.timeout      = SEC_PARAM_TIMEOUT;
    m_sec_params.bond         = SEC_PARAM_BOND;
    m_sec_params.mitm         = SEC_PARAM_MITM;
    m_sec_params.io_caps      = SEC_PARAM_IO_CAPABILITIES;
    m_sec_params.oob          = SEC_PARAM_OOB;
    m_sec_params.min_key_size = SEC_PARAM_MIN_KEY_SIZE;
    m_sec_params.max_key_size = SEC_PARAM_MAX_KEY_SIZE;

sd_ble_gap_sec_params_reply()を追っていったが、m_sec_paramsは別にstaticで持つほどでもないように見える。
中で値を詰め替えているみたいだ。

#define SEC_PARAM_TIMEOUT               (30)
#define SEC_PARAM_BOND                  (1)
#define SEC_PARAM_MITM                  (0)
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_NONE
#define SEC_PARAM_OOB                   (0)
#define SEC_PARAM_MIN_KEY_SIZE          (7)
#define SEC_PARAM_MAX_KEY_SIZE          (16)

• timeout : SMPトランザクションかセキュリティ要求のタイムアウト時間(秒)
• bond : bondingの有無
• mitm : Man In The Middle保護要求
• io_caps : IO能力
• oob : Out Ob Bandデータの許容
• min_key_size : 符号化鍵の最小サイズ(byte)。7～16。
• max key_size : 符号化鍵の最大サイズ(byte)。min_key_size～16。

わからない用語が出てきたので、それぞれ調べる。

• bonding
• ペアリングのことらしい。Bluetoothのチップでは、よくbondingという表現を見かける。微妙に違いがあるのかもしれない。
• Man In The Middle(MITM)
• ネットで調べると、MITM attackという言葉が出てくる。
  Core_v4.1.pdf p.216「5.2.3 Man-In-The-Middle Protection」を読むと・・・2台のデバイスを接続させようとしているときに、不正な第三者(attacker)と接続してしまうことを指しているようだ。each otherとあるから、それぞれのデバイスは相手とつながっていると思ってるけど、実は間にattackerが入っている(Man-In-The-Middle)、ということか。
  これをさせないために、Secure Simple Pairingという方法を採るらしい。お互いしか知らない数字を入力させるような形だ。
• こういうモデルがあるようだ
• Numeric Comparison
• Just Works
• Out of Band
• Passkey Entry
• IO能力(GAP IO capabilities)
• define値としては5つ用意されている
• DISPLAY_ONLY : Display Only
• DISPLAY_YESNO : Display and Yes/No entry
• KEYBOARD_ONLY : Keyboard Only
• NONE : No I/O capabilities
• KEYBOARD_DISPLAY : Keyboard and Display
• Core_v4.1.pdf p.2251がそれか(Vol.3 Part.H Security Manager)。
• 接続成立後、Secure Simple Pairingのサポート状況と、IO capabilityを交換する。
• IO capabilityを交換する理由は、Simple ParingのAuthentication State 1で認証アルゴリズムを決定するため。
• inputは「入力できない」「Yes/Noくらいならできる」「数字キーボードあり」
• outputは「表示できない」「数字出力できる」
• これを組み合わせると6パターンになるが、「input：Yes/No」「output：No output」の組み合わせについてはアルゴリズムがない。
• OOB認証が使える場合は、そちらを優先するのかな？
• Out of Band
• これはNFCでSimple Secure Paringをしたときにも出てきたが、対象とする機器以外を指す。狭義では、別の周波数帯、ということになるのか。
• 認証アルゴリズムについて細かいことはCore_v4.1.pdf p.1958に書いてあるので、省略。
• 符号化鍵のサイズ
• p.2252そのままだ。
• あまり考えず、このままの値でよいのかな。

---

そういうわけで、BLE_GAP_EVT_SEC_PARAMS_REQUESTについては以下のように扱うことになるだろう。

• サンプルと同じく、sd_ble_gap_sec_params_reply()でセキュリティ設定を返す。
• おそらく接続直後か、接続する手前か、その辺りで呼ばれるのではなかろうか。
• セキュリティ無し無しならばサンプルのままでよい。
• セキュリティ有りにしたときの動作は、未調査。