02tools.re

= 機材選び

//lead{
パケットを集めるだけ, と決まったからにはひたすら猛進するだけです.
ただし時間・場所・やり方の都合上, ただPCを持ってうろつくというのは
やりたいことにあまり即していません.
ここでは今回の要求にマッチしそうなキャプチャデバイスをでっち上げてみます.
//}

== キャプチャデバイスの要件
#@# DONE

キャプチャをするにあたり一番一般的なのは手持ちのノートPCでwireshark立ち上げて,
という手段ですが特にコミケという場所をターゲットにする場合これはあまり
得策ではありません. 今回やりたい情報収集にあたっては以下の要素が重要になります.

 1. 持ち運び
 2. 連続稼働時間
 3. キャプチャできるデータの多さ
 4. お値段

=== 持ち運びが容易であること
#@# done

持ち運びが容易であることは重要なポイントです. これには@<strong>{形状, 重量, 耐久性}
といった要素が絡みます.
コミケという一番過酷な環境を想定する場合, 列待機の間, お買い物で移動している間
などさまざまなシチュエーションで邪魔にならず静かに動き続けられることが
要件となります.


できればいろいろなところに持って行きたいのでコンパクトであってほしいものです.
最低でも鞄に入るサイズではあるべきでしょう.

持って移動するという都合上, キロ単位で重いものは対象外となります.
特に夏のコミケ期間中はただでさえ水分を大量に持ち歩くのでそれがおろそかに
なるような重さであっては困ります.


またそれなりに頑丈である必要があります.
人混みに揉まれたときに壊れないことというのがその主たる要求ですが,
夏は炎天下の暑さや会場内での熱気に, 冬は凍えるような日の出前の寒さに
おいても正常に動作し続けられることが要求されます.

その他, 変な音を立てない, 変な光をださないといった要件はありますが
基本的には以上に挙げた3点が満たすものが必要です.


=== 長時間稼働できること
#@# DONE
連続稼働時間も重要な要素です. 具体的には電源供給の問題を解決する必要があります.
コンセントがあるような環境であればこれは問題になりませんが,
コミケの様なイベントでサーベイをする場合どれくらいの時間を計れるかは
バッテリーやそれを用いて駆動されるデバイスにより変わってきます.

時間的要件を考えるにあたりコミケでは@<table>{tbl_comicket_sched}に
挙げるタイムスケジュールになっていることを考慮する必要があります.

//table[tbl_comicket_sched][コミケのタイムスケジュール]{
時間	イベント					来場可能時間からのoffset
----------------
4:30	来場してもよい時間				00:00
5:43	りんかい線下りの始発到着(休日)			01:13
5:44	りんかい線下りの始発到着(平日)			01:14
5:53	りんかい線上りの始発到着(平日&休日, 臨時)	01:23
7:30	サークル入場開始				03:00
10:00	コミケ開会					05:30
16:00	コミケ閉会					11:30
//}

一般参加で動点観測する場合は列に並ぶところから,
サークル参加で定点観測するなら7:30あたりから閉会までが最大限
とすると9時間から12時間程度動き続けられると全体をカバーし続けられそうです.
とはいえこれは"最大"なので, 開会から閉会までの6時間をまずはベースとしましょう.

バッテリーに関して, コミケではカタログ等に以下の様な制限についての
記述が存在します@<fn>{rule}.
//quote{
3. バッテリー類
自動車用などの大型バッテリー類は液漏れした際に危険なため.
携帯電話, ノートパソコン等で私用されている密閉された
小型バッテリーは, 2〜3個であれば持ち込んでもかまいません.
//}

//quote{
- その他持ち込みが禁止されている物:
発電機, 大型バッテリー (以下略)
//}

//footnote[rule][「コミックマーケット86 DVD-ROMカタログ」, P.15「コミケットのルール」および P.33 「持ち込み禁止及び制限について」より抜粋]

要するに発発や鉛蓄電池といった可燃物やひっくり返したら危ない物を使うな,
というのが基本のようです.持ち運びや取り扱いの問題もあるのでこれらは
やめておいたほうがよいでしょう.

基本は, デバイス内蔵バッテリーで何とかする,
USB給電可能なモバイルバッテリーやラジコン用のバッテリーなど
を用いるといった方法が良いようです.
電源周りは特に夏場などで温度等が怖いので可能な限り信頼可能な
既製品を使いたいところです.



=== たくさんキャプチャできること

状況を可能な限り正確に知るためには, 最大限フレームを集められることも必要です.
ここで言う「最大限」を実現するために考慮しなければならないのは
ターゲットにできるチャネル(周波数帯)の広さと
フレームの受信能力/性能です.

基本的に一つの無線LANデバイス(チップ)は一度に一つのチャネルでしか動作
することができません. なので可能な限り多くのフレームを集めるためには
可能な限り多くのチャネルでキャプチャができるようにする必要があります.
これに当たっては基本的には以下のいずれかの方策を取ることになります(組み合わせも可).

 1. チャネルを一定時間で変える
 2. たくさんの無線LANデバイスを載せる

チャネルを一定周期で変える(ホッピングさせる)方式は少ないデバイスで
より広い数のチャネルを擬似的にカバーできるという利点があります.
後述する「お値段」には大変お優しいのですが,
あるチャネルに滞在する時間は他のチャネルのフレームを
取りこぼしてしまいます.

#@warn{ここに図: ホッピング}

この, 取りこぼしてしまう時間をなくすにはデバイスを大量に載せればいいのですが,
2.4GHz帯で13のチャネル, 5GHz帯で19チャネル@<fn>{5ghz_19ch}となり
完全なカバーをするには計32チャネルつまり32個もの無線LANデバイスが必要になります.

//footnote[5ghz_19ch][これは20MHz幅モードの場合のプライマリチャネルの数]

#@warn{ここに図: チャネル分布}

精度を追い求めるのであればこれを丸っとカバーしたいところですが,
主に持ち運びや, デバイスの調達(予算的な意味で), デバイスの電源確保といった
面で難易度が上がっていくので基本的にはいろいろと削ってがんばることになります.
手っ取り早く削減する方法としては, だいたいのデバイスがプリセットで
使っているようなチャネルだけをターゲットにするというプランがあります.

2.4GHz帯では 1, 6, 11 チャネルがよく使われるチャネルとして挙げられます
@<fn>{ch136_why}.
第一章の図1.1などでもうっすらとですが,
この3つのチャネルのUtilizationの山が高くAPの密集具合もなんとなく高い(?)
ことが見て取れるかと思います.
特に1チャネルは, 多くの機器(モバイルルータやAP)にて初期値のチャネルとして
設定されています.
もちろんチャネルの自動選択機能を利用している場合や, 上記のセオリーを知ってあえて
(干渉はするけれども)違うチャネルを設定している人は一定数いるようなので
完全なカバーにはなりません.
ただしおおよその部分を抽出することはできます.

//footnote[ch136_why][これは, 2.4GHz帯で干渉が発生しないようにチャネル設計をすると, この3つのチャネルを選ぶのがベストプラクティスになるという共通認識によるもの]

5GHz帯ではチャネル幅が広くそれぞれの領域で法規や特性もことなるため
カバーが難しいですが,
基本的には下位のW52とよばれる36/40/44/48チャネルに集中することが多いようです.
これらのチャネルは室内限定でレーダーなどとの干渉をよける仕組みである
DFS(Dynamic Frequency Selection)を動作させずとも良いため
据え置きのAPにて好まれる傾向にあります.
また2.4GHzにおける1チャネル同様, 最下位のものがプリセットに多いというのも
同じです.

====[column] 受信能力とホッピングによるサーベイと.

ここまでの流れでは「ホッピングでチャネルを一つ一つ舐めていくとかありえない！」
的な論調でお話を進めてきました.
が, OmnipeekやAirMagnetなどWi-Fiサーベイツールとして名高い多くのソフトウェアで
採用している手法ではそこまで多くの無線LANインタフェースを必要とはしていません.
ローミングの検証をしないのであれば2.4/5GHz両対応のデバイス一つだけを駆使して
基本的にはホッピングのみで役に立つ情報の提示ができています.

要はどう手元にある情報で分析するか次第なのでこれまでに述べたような
ある種偏執的なまでのキャプチャというのは基本的には不要です.
どんなにカバー範囲を広くしようとしても電波的な問題
(受信側アンテナの性能, 障害物の存在, 送信機との距離, キャプチャ場所)やOS側の
ドライバ/スタック/キャプチャソフトウェアの問題でdropするフレームが
出てきてしまうのは避けようがありません.

が, 冒頭でも述べたようにキャプチャというのは身近かつ手軽な
手法なのでここではそっちの方向に可能な限り突っ走っています.


#@# memo
#@# キャパシティ
#@#/ パケットをきちんと拾いたい
#@#/ 広い周波数
#@#/ 2.4GHz で 13ch, 5GHzde...
#@#/ トレードオフ
#@#/ とりあえず2.4no代表である1,6,11
#@#/ drop少なく
#@#/ ドライバ, bus, プロセッサの能力
#@#/ デバイス間の差異(たとえば一部フレームは上げないなど)

=== お値段

経済性, それは最後の要件にしてもっとも重要なポイントです.
これまでに述べたような, 薄く軽く丈夫で長時間動作したくさんキャプチャができる
であろうデバイスの候補はいくつも挙がります.
しかし調達できないのであれば問題外です.

具体的にどこがラインかは難しいところですが,
少なくとも薄い本の予算が削られる程度であっては困ります.


== 候補の例

//lead{
前節で上げた要件を満たすデバイスについてここでは候補となり得るものを挙げ,
それぞれについて検討・検証をしていき, 適切かつお手頃なものを考えていきます.
//}

=== ノートPC

まず手軽なものとして挙がるのがノートPCです.
利点としては PCIeデバイスとして無線LANデバイスが載っていること,
UIも付いているのでいざという時の操作が楽であること,
いろいろと環境を整えるのが楽であることが挙げられます.
無線LANデバイスは通常一つしか載っていないので
USBの無線LANアダプタを生やす必要があります.
ただし, これ以降にあげる他のデバイスでもこれは同条件である一方, 
ノートPCではUSBへの給電周りでの心配がある程度不要というのは利点になるでしょう.
またキャプチャにいつもと同じwireshark/tcpdump/tshark等が使いまわせる
という点もGood Pointです.


欠点として一番に来るのはやはりお値段でしょう.
特にこのお値段がある程度でないと重量やバッテリー駆動時間が
ネックになる場合があります.


なお, その上で動かすOSにも注意が必要です. Windowsは基本的にはあまり
推奨できません. これは, 上でWiresharkを動かすにあたり802.11フレームを
拾えるMonitorモードが使えないという致命的な仕様があります
@<fn>{airpcap_only}.
なのでLinuxに入れ替えるか, またはOS X on MacBookというのが
懸命な選択肢です.

//footnote[airpcap_only][AirPcapを利用時にのみこれが可能になります.お高いので当然却下]

#@# 評価軸的な図を作ってみる?


=== タブレット, スマホ

ノートPCの代替としてタブレット/スマートフォンを用いるという手があります.
よっぽどのものでないかぎり数万円でかなり高性能な部類のデバイスが手に入るので
お財布にはそこそこ優しく, ノートPC同様オペレーションのUIがあるというのも便利です.
Android 端末を用いる場合,
キャプチャ用のアプリケーションとして "Android Pcap"@<fn>{android_pcap}
というのも公開されており手軽に始められるのも利点です.

//footnote[android_pcap][http://www.kismetwireless.net/android-pcap/]

ただしこのアプリでは内蔵の無線LANデバイスはキャプチャに使えません.
対応しているのはRealtekのRTL8187チップを使ったUSB無線
LANデバイスに限定されています.
外部デバイスなのでOTGケーブルで接続する必要があり, 外部バッテリーの
利用が基本的には難しくなります.
本体に給電しつつデバイスもできるようなケーブルが売られている
ようですが
改造が必要だったり端末の種類やバージョンに応じて相性があるらしく
万全の解決策とはならないようです.


さらに, このチップが載ったデバイスは基本的に日本では流通していません.
一応amazonでは販売していますが, 技適の通った(日本国的に)まっとうなデバイスは
一つもないので注意が必要です.
電波を出さなければOKですが, 普通に使うとお縄になります.
とはいえこのアプリ, ソースは公開しておりRTL8187のデバイスドライバは
Javaのユーザランドドライバとして書かれていたりします.
なのでやる気と根気と執念があれば任意のデバイスによるキャプチャも可能になるかも
しれません.
実際にはroot権限を奪取する, ubuntu for androidの様な普通っぽいOS
を突っ込む, といった手段によりもうすこし便利にできたりするかもしれませんが,
そこまではまだ検証できていません.


最近出てきた他の候補としては
Surface Pro 3あたりも普通のWi-Fiアナライザ/サーベイツールを
動かすためのデバイスとしては魅力的です.
ただし今回はキャプチャ目的であり, ノートPCの節で述べたように
Windowsのキャプチャ環境は正直微妙なので見送ります.
お値段も高いですしね…


=== 組み込みボード

おあつらえ向きのデバイスが無いのなら作ればいいじゃない！
ということで適当な組み込みボードを使って1から自作するという道もあります.
この場合, 電源やらソフトウェアやらは自分でどうにか作るとか既存の物を
寄せ集めるといった試行錯誤が必要ですがそれなりに柔軟性があります
(その分クオリティにも悪い意味で柔軟性があります).
こういったボードの候補としてあげられる有名どころは Raspberry Pi, BeagleBone,
IntelのGelileo, Arduinoといったあたりでしょうか.

キャプチャが目的なので, 適当な無線LANデバイスが載っているor載せられることと
tcpdump/tshark/wireshakrあたりがさっくりと導入できることが条件にはなりますが
どれも(Arduinoを除けば)普通のLinux板なのであとは扱い易さ, 入手性といった
趣向の問題になりますが一点, 電源周りについてのみ気をつける必要があります.


まずは携帯可能な, かつコミケに持ち込み可能なバッテリーで稼働できることと.
これが満たされる必要があります. 理想的にはスマホ用のモバイルバッテリーで
長時間稼働できることでしょうか.
この板自体に対する電源供給に加え, それに接続させて利用する無線
LANデバイスへの電源供給についても考慮が必要です.

特にRaspberry Piで顕著ですが, USBバス配下にEthernetデバイスもぶら下がっている
ためか無線LANデバイスを2, 3個挿すとこれらのデバイスすべてが認識されなくなります.
PCに接続したUSBハブでも似た様なことは起きますが, それよりもだいぶ同時接続
可能なデバイスが少ないと見た方が良いでしょう.