2014/12/31

[年末まで表示]サイトの紹介

いつもhiro99ma blogを見ていただき、ありがとうございます。
サイトを整理したのでご紹介します。
  • hiro99ma blog:ここ。コンピュータの技術系。
  • hirokuma work:フリーランスのお仕事用。
  • hiro99ma無駄話:技術系じゃない内容。
 今までラベルで分けていましたが、読みにくくなったので分けました。

2014/11/01

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

[LINE]スタンプの申請が1つ通ったので、その感想を書く

8月3日に申請したLINEクリエーターズスタンプが、10月31日に承認された。

みどりネコ

LINEネタは無駄話ページに書いているのだが、こっちにも紹介しておこう(あまり売れないらしいので)。



クリエーターズスタンプは、LINEのアカウントさえあれば無料で始められる。
つらいところは、まずは絵を40枚描く、というところだろう。
私はあんな気楽そうな絵ではあるものの、そんなに速く描けないので、絵が揃うまでに時間がかかるのだ。
また、ある程度のテーマで描くことになるので、描きながらネタがなくなったりしてね。

それを申請に出して、承認が通るところが次のつらいところだ。
どのくらいかかるのか、さっぱりわからないのだ。
今回の私の場合は、ほぼ3ヶ月かかって申請が通ったことになるが、もう1つ申請を出しているスタンプはもう6ヶ月も審査中のままだ。
「あと○ステップで審査完了」みたいなものが見えないため、やきもきしながら待つしか無い。

最後のつらいところは、売れる・売れないだろう。
これはまだ私も始まったばかりなのでわからないけど、売れる人と売れない人の差は激しいそうだ。
有名な人はともかく、私みたいに普通の人はなかなかねぇ。
それに、承認がいつ通るかわからないので、収入の当てにするのも難しそうだ。

定期的にスタンプを登録して、どれか1個でもメジャーになって、それにつられて他のスタンプも売れる、みたいな構図しかないのかなぁ。

2014/10/30

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

では、nRF51822で作ったサンプルのイベントハンドラの中身を見ていこう。
私のわかる範囲で、になるから、期待しないよう。


BLE_GAP_EVT_CONNECTED
BLE_GAP_EVT_DISCONNECTED

これは、ワンセットでよいだろう。
サンプルはPeripheralなので、以下の図のタイミングで通知されると思う。

image

 

Connection状態になったら、m_conn_handleをハンドル値で更新しているし、Standy状態になったら無効値にしている。
Standby状態になったら、すぐにAdvertising状態に遷移し、Advertisingを始めているようだ。


ここで、もう行き詰まった。
これ以外のイベントは、nRF51 SDKのドキュメントを読んでも意味がわからないからだ。

しかし、イベントのenum値をネットで検索すると、わかりやすい説明が出てきた。
説明はdevzone.nordicsemi.com、つまりnRF51の元だ。
なんでインストールしたSDKよりも説明がわかりやすいんだー!

わかりやすいというか・・・このドキュメントがないと、BLE仕様と実装との関連づけができないような気がする。
リンク名からすると、4.3.0のようなんだけど、Nordicのサイトからはもうダウンロードできないようなのだ。。
あきらめて次回からは、サイトの情報を見ながら読んでいくか。

2014/10/29

[html]innerHTMLは、中の要素だけ書き換えられる

苦手なものは色々あるが、とにかくスクリプト言語は勝手がわからないので苦労する。
ちょっとHTMLとかJavaScriptとかを触らないといけないようになり、慌ててやっているところだ。

ありがちなのかもしれないが、ボタンを押すとHTMLの中身を書き換える、というような要求があった。
ああ、書き換えたHTMLファイルを作って、それを読込ませるようにせんといかんのか、と思っていたのだが、そういうことはやらず、innerHTMLなるもので一部の書き換えができるようなのだ。
ほほぅ(←初心者の証)!

 

しかし、哀しいかな初心者。
innerHTMLでどこがどう書き換えられるのかがわかっていない。。

image

"kuma"の適用範囲は、こう。

image

要素の内容だけなのだ。

なんでこれを勘違いしていたかというと、こうやって意図通りに動いたからだ。

image

「よく理屈はわからないが、タグを同じにしておけば自動的に置き換えられるんだ!」と理解していたのだな。
無知って怖い・・・。

 

現在表示されているブラウザ画面が、どういう解釈の元に表示しているかがわかればよいのだが、表示しているソースを見ても自分で書いたものが出てくるだけでわからん。

と思ったら、Firefoxだと「インスペクタ」で見ることができた。

image

こういう、何をしたらどうなる、とか、こうしたいときはだいたいどうする、という材料を持っていないのでイライラするんだろうな。