ページ

2014/07/30

[ble]ClientとServer

1ヶ月も経たないのに、もう忘れてしまった・・・。
が、あのときは調べるだけで手一杯だった。
今度は、吸収する番だ!

 

image

MasterとCentral、SlaveとPeripheralについては、同じになると思っている。

Core_v4.1の図で、Initiatingになった方がMaster、Advertisingになった方がSlave。
Vol.6 Part Bの図。

image

 

こちらは、Vol.3 Part Cの図。
AがInitiatedしているので、Masterと言えよう。あるいは、AがInitiatedしたいので、L2CAPではMasterになるというのか。

image

 

それに対して、ServerとClientは意味合いが異なる。
Vol.3 Part Gの図を見るとよいか。

image

だいたい上記の作りにする場合、SensorがPeripheralでComputerがCenterになるだろう。
でも、データを持っているのはSensorの方で、Computerはそれを取得しに行くことになる。
つまり、SensorがServerで、ComputerがClientだ。

でもこれが、Sensorとなっている方がComputerの状態を定期的に監視してブザーを鳴らすデバイスだったらどうだろうか。
やはりSensorとなっている方はPeripheralでComputerはCentralになるだろうけど、データを持っているのはComputerで、Sensorがそれを取得しに行くことだろう。
そうなると、SensorがClientで、ComputerがServerだ。

ってことでいいんだよね。

2014/07/29

[nfc]HCEがキーワードらしい

http://itpro.nikkeibp.co.jp/atcl/news/14/072400197/

2014年のキーワードは、HCEらしい。
まあ、もう2014年も半分が終わったのに・・・とか言っても仕方が無い。
それに、どのクオーターで数えるのかは人それぞれなので、細かいことは捨て置け。

私は、HCEっていうのはAndroidの機能名だと思っていた。
TgInitAsTargetコマンドとかでR/Wをターゲット状態にしたとき、そのコマンドをさばくのはホストだ。
だから、カードエミュレーションする≒ホストがカードエミュレーションする、という認識だったのだ。
もちろん、モバイルのFeliCaチップのようなセキュアエレメントを使うようになっているものは、チップとセキュアエレメントが勝手に通信しあって解決してしまう。
そこがセキュアエレメントのセキュアエレメントたるゆえんだ。

HCEすると、ホストが全部やるので、データはつーつーになる。
だから極端に言えば、適当なところでメモリを抜き取ると、通信したデータが取得できるだろう。
でもまあ、そんなことをいえば、HTTPSとかの通信だってどこかでメモリに落としてるんだから、拾おうと思えば拾えるんじゃないかと思う。
課題は色々あるんだけど、私はあまりセキュリティに詳しくないせいもあって、楽観的だ。
なんとかなるんじゃないのー、という感じ。
いや、詳しくなった方がいいんだろうけど、もう私の許容範囲を超えてますわ。

 

そういうのはよいとして、HCEってなんだろう?というのがもやもやとしている。
私の認識は、今のところ、こう。

  • NFC Forumのカードエミュレーション
    • 特に機能を限定せず、タグ以外のものがカードエミュレーションすること全般を呼んでいる
  • AndroidのHCE
    • 今までCardEmulation機能をユーザに提供していなかったAndroidが、Type4かつSEなしで可エードエミュレーションできるようになった
  • NFC ForumのHCE
    • SE必須となっていた内容についてカードエミュレーションすること?

私はNFC Forumのメンバーじゃ無いので、内部でどういう話が進んでいるのかはわからない。
非メンバーが見ることができる技術仕様書には、SEが絡みそうな話は出てきてなかったと思う。
だから、NFC ForumがHCEの話をすると「?」と思ってしまうのだった。

http://nfc-forum.org/newsroom/nfc-forum-statement-regarding-host-card-emulation-hce/
こちらを読むと、NCIにHCE実装について書いてあるようだ。
NCIは・・・読んでない・・・。

ただ興味深いのは、上記リンクにはNFC-A, B, FのようなNFC Forumの区分ではなく、ISO 14443やJIS X6319-4のような規格名になっていることだ。
ISO 14443は見たことがないのだが、JIS X6319-4はこちらから見ることができる。
X6319だと、Read w/o Encryptionとか、Write w/o Encryptionじゃない、ReadやWriteというコマンドがある。
これは、認証しないと使えないコマンドで、確か通信経路も含めて符号化されるんじゃ無かったっけ。

NFC Forumの、非会員で見ることができる技術仕様書には、データの保護を行うための符号化については取り決めが無い。
だからかねー、というところだ。
私の予想では、LLCPSでセキュアなP2Pをする方向になるかと思ってたけど、やはり既存の資産は優先されますわな。

2014/07/27

[ble][nrf51]Write w/o Encで書き込んだUUIDをiBeaconする

FeliCa PlugからUUIDを書き込み、そのUUIDでAdvertisingというかiBeaconというかをするようにできた。
https://github.com/hirokuma/nrf51822_felicaplug/commit/3b8bb6329223354209f7531836184650a800d30b

今朝まで、なぜかAdvertisingさせようとするとHardFaultしていたのだが、なぜか直った・・・。
Eclipseかgdbか・・・。

ブロック0に1ブロック書き込みすると、そのデータをそのままUUIDとしてiBeaconのデータを投げる。
Major, Minor, RSSIなどは固定だ。
もう1ブロック増やして、そこも可変にしてもよいのだけど、手元に1ブロックアクセスするNFCアプリしか作っていなかったので、もういいや。

なんでこんなもん作ったかというと、FLASH書き込みを行わずに外部からUUIDを書き換えられると便利かも、と思ったからだ。
iBeaconアプリの評価とかによいかもね。

image

まあ、私自身はiBeaconにあまり興味を持ってないのだけど、OSが動作確認に使えるという点では便利だ。
SNEP実装したときにAndroid Beamで動作確認するような、そんな感じだ。

image

LEDは3つ。
搬送波検知が左、Advertising中が真ん中、エラー発生が右。
まあ、本当に運用するならAdvertising中のLEDは無しだな。

 

さて、簡単そうなところは動かせたので、次はGATTとかそういうやつかな。

AutoHotkey

Windowsでキーカスタマイズするのに、AutoHotkeyを使っている。

最近になって思うのだが、作業を便利にするのはいいとしても、キーカスタマイズはあまりやらない方がよいな、と。
一度キーカスタマイズしてその環境に慣れてしまうと、他の環境でも同じキーカスタマイズにしないとストレスがたまってくる。

  • 一時的に他のPCを使うとき、疲れる
  • 一時的に人にPCを貸すとき、びくびくする
  • PCをセットアップするのに時間がかかる
  • 気に入るカスタマイズが見つかるまで、いろいろ試して時間がかかる

などなど、弊害多数。
にもかかわらず・・・一度やって慣れてしまうと、もうだめなのだ・・・。

以前までは、窓使いの憂鬱とか、猫まねきとかを使ってたんだけど、Windows7になってから使えなかったので、AutoHotkeyに乗り換えた次第だ。
レジストリの書き換えが無いので、アプリさえ立ち上げなければ元の環境に戻れるというのが助かる。
CtrlとCapsLockの変更については、このツールではできなかった気がする。

^h::Send,{backspace}
$^f::Send,{right}
^b::Send,{left}
^n::Send,{down}
^p::Send,{up}
sc029::Send,{Esc}
^+f::Send,^{f}

私はEmacsは使えないのだけど、カーソルをCtrlキーのキーバインドで実現できるのは気に入ったので、そこだけ採用した。

そうすると、検索をCtrl+Fに割り当てているソフトが使いにくくなる。
では、ほとんど使わないCtrl+Shift+Fを押すとCtrl+Fになるようにしておこう、というのが上記だ。
$^fと$を付けないと、^+fによる^fがrightに置き換えられてしまうようだ。

2014/07/26

[nrf51]FeliCa Plugの時間

ロジアナが来たので、FeliCa Plugの通信速度などを計測。
SPIは1Mbpsにしている。

image

最初の2byteから184us空いてデータ受信をしている。
これは、FeliCa Plugが送ってくるデータサイズがわからないので、1byte目のコマンドと、2byte目のブロック数を読んでから全体の受信サイズを決めているところなので、そこの間だ。
まあ、本当はブロックリストエレメントが2byteなのか3byteなのかをさばかないといけないのだけど・・・省略した。
だって、2byteのブロックエレメントくらいしか使わんやん!

そのあとは、nRF51 SDKに任せているところだ。
データ間隔は12.2usというところか。
最初の2byteだけ連続しているのは、SPIの送受信ともに余裕バッファが1つあるので、そこに貯める間隔が早くなっているだけのようだ。3byte目までの時間が空いているのは、結局そこが空くまで待つからだろう。

そんなわけで、時間的にもそんなに悪くない作りになったんじゃないのかな。
ここまでの成果は、githubにも上げてます。