続・ららら、(無線的に)素敵なComiket Space

続・ららら、(無線的に)素敵なComiket Spacenkaneko(@n_kane)-ここに3つのpcapファイルがあるじゃろ？-

pub

このスライドの内容下記のスライドの続き

Agenda前回までのあらすじ

今回の測定

測定機器・環境

測定結果からの考察

今回の反省／振り返り

まとめ

前回までのあらすじコミケ(C84)でWi-Spyを動かしてみた、というお話

自宅環境

東館ガレリア

西館ホール


自宅環境

東館ガレリア

西館ホールこれはひどい


自宅環境

東館ガレリア

西館ホールこれはひどい

完

前回の反省点ひどいのは分かった

!

!

データが少ない


!

!


では、どれぐらいひどいのか？定量的な「ひどさ」とは？

とりあえず計測してみた、程度


!

!




→ 指標について考えてみよう

→ 一定の方法で観測してみよう


!

!




→ 指標について考えてみよう

→ 定点観測・一定時間以上の観測

こんなかんじでまとめてました

今回(C85)の測定

パケットキャプチャしてみました

スペアナのロギングもやってみたいが準備不足

パケットキャプチャはすぐにできそう

パケットキャプチャしてみました

スペアナのロギングもやってみたいが準備不足

パケットキャプチャはすぐにできそう

パケットキャプチャから何か分かることはないだろうか？というのを実際に取ってみて考える。

測定機器

こんなかんじで測定してました

こんなかんじで測定してましたキャプチャ用Nexus7

(Android端末)

USB OTGケーブル

USB無線LANアダプタ

Android Pcap動作中

機器選定における要件

そこそこの時間バッテリーが保つこと

!

持ち運びしやすい重さ・大きさであること

!

キャプチャができる機器であること

バッテリー的制約計測時間次第だがそこそこ長時間保つ必要あり

バッテリー的制約計測時間次第だがそこそこ長時間保つ必要あり

開幕が10:00、終わりが16:00列も含めると最早で6:00？最低でも6hぐらい機器本体に加えて無線LANアダプタへの電源供給分も….

筐体サイズ・重量の制約(動点観測なら)持ち運べるサイズ

(定点観測なら)スペースにおけるサイズ

筐体サイズ・重量の制約(動点観測なら)持ち運べるサイズ

(定点観測なら)スペースにおけるサイズ

ひとまず小さければ小さいほどよい

キャプチャ可能という制約Linux/MacならWireshark+無線LANデバイスが最強

!

WindowsならAirPcap必須

!

iOSはStumblerが利用可能

!

Androidは”Android Pcap”が利用可能

キャプチャ可能という制約Linux/MacならWireshark+無線LANデバイスが最強

!

WindowsならAirPcap必須

!

iOSはStumblerが利用可能

!

Androidは”Android Pcap”が利用可能

ただし、デバイスの制約(※)あり

だったが、今は無理そう。JB必須？

高いので却下

前述のバッテリー・重さ問題で却下

(※)・・日本で出回ってないRTL8187のみ対応

必要な情報がこれまでのやり方で取れる

機器選定における要件

そこそこの時間バッテリーが保つこと

!

持ち運びしやすい重さ・大きさであること

!

キャプチャができる機器であること

Nexus7に決まったワケ

Android Pcapで5～6hは保つ開幕(10時)から15時ぐらいまではいける

299g, 7インチタブレット

Android Pcapでなんとか

測定環境

測定地点・時間(1, 2日目)

スペースもってないので、動点観測

計測用Android端末を鞄に入れてあちこち歩く

一応GPSロギングをしてみる(期待薄)

測定地点・時間(1, 2日目)

スペースもってないので、動点観測

計測用Android端末を鞄に入れてあちこち歩く

一応GPSロギングをしてみる(期待薄)

思ったよりはとれてる？ 30s間隔なので微妙

GPSログはこんな感じ

測定地点・時間(3日目)自スペース(西せ16b)で定点観測

ここらへん



ここらへんにAndroid端末を置いておく

測定方法

Android Pcapでチャネルを1に固定

アンテナは可能な限り外に出しておく

測定開始したらそのまま放置

測定結果

キャプチャデータ1日目 (動点観測)

12/29 09:49～12:06 → 891189フレーム, 163MB

2日目 (動点観測)

12/30 09:52～13:39 → 1191454フレーム, 236MB

3日目 (定点観測)

12/31 10:01～15:00 → 2170674フレーム, 389MBpcapファイルは

参照晒していいか良く分からんのでとりあえず隠し

単位時間毎のフレーム数(きちんとフレームが取れてるとして)流速

フレーム数観測時間 FPS

1日目 891189 02:17:13 108.2

2日目 1191454 03:37:12 91.5

3日目 2170674 04:48:55 125.2

ユニークAP/ステーション数見えたAPおよび無線LAN端末の数の総計

AP数無線LAN端末数

1日目 1160 18154

2日目 1850 28331

3日目 974 17564

再送率再送フレームの数、および全体に対する割合

総フレーム数再送フレーム数再送率(%)

1日目 891189 184138 20.7

2日目 1191454 258412 21.7

3日目 2170674 643440 29.6

フレームタイプの比率見えたフレームタイプの割合

1日目

9%0%0%0%1%0%

31%

23%

0%2%0%0%6%1%

14%

0%0%0%0%11%0%1%

1日目

9%0%0%0%1%0%

31%

23%

0%2%0%0%6%1%

14%

0%0%0%0%11%0%1% Beacon

Probe Response

Probe Request

ACKRTS

1日目

9%0%0%0%1%0%

31%

23%

0%2%0%0%6%1%

14%

0%0%0%0%11%0%1% Beacon

Probe Response

Probe Request

ACK

ここらへんがデータ

RTS

2日目

5%0%0%0%1%0%

32%

17% 0%1%0%0%6%

3%0%

18%

0%0%0%0%0%

11%0%4%

2日目

5%0%0%0%1%0%

32%

17% 0%1%0%0%6%

3%0%

18%

0%0%0%0%0%

11%0%4%

BeaconProbe Response

Probe Request

ACKRTS

2日目

5%0%0%0%1%0%

32%

17% 0%1%0%0%6%

3%0%

18%

0%0%0%0%0%

11%0%4%

BeaconProbe Response

Probe Request

ACKRTS


3日目

2%0%0%4%3%0%

38%

16%

0%2%0%0%1%2%0%

18%

0%0%0%0%12%

0%1%

3日目

2%0%0%4%3%0%

38%

16%

0%2%0%0%1%2%0%

18%

0%0%0%0%12%

0%1%Beacon

Probe Response

Probe Request

ACK

3日目

2%0%0%4%3%0%

38%

16%

0%2%0%0%1%2%0%

18%

0%0%0%0%12%

0%1%Beacon

Probe Response

Probe Request

ACK


フレームタイプごとの長さの比率見えたフレームタイプごとの長さの割合

radiotapヘッダがなく、Air Timeの計算ができない

ここでは苦肉の策でとりあえず長さだけ….

本来的には各フレームごとにIFS, CW, Preamble の加算をし、PLCPヘッダ+フレーム長を転送レートで割った値の総和(AirTime)を比較するのが筋らしい例はIEEE 802.11-11/1031r0 “Air-time Consumption by Beacon and Probe”あたり参照

1日目

1%0%0%0%1%0%

49%

17%

0%0%0%0%

10%

0%

20%

0%0%0%0%1%0%0%

1日目

1%0%0%0%1%0%

49%

17%

0%0%0%0%

10%

0%

20%

0%0%0%0%1%0%0%

Probe Response

Beacon

Data

Probe Request

QoS Data

2日目

1%0%0%0%2%0%

49%

12%0%0%0%0%

9%

0%0%

25%

0%0%0%0%0%1%0%1%

2日目

1%0%0%0%2%0%

49%

12%0%0%0%0%

9%

0%0%

25%

0%0%0%0%0%1%0%1%

Probe Response

Beacon

Data

Probe Request

QoS Data

3日目

0%0%0%0%1%7%0%

51% 13%

0%0%0%0%1%0%0%

24%

0%0%0%0%1%0%0%

Probe Response

Beacon

Data

Probe Request

QoS Data

3日目

0%0%0%0%1%7%0%

51% 13%

0%0%0%0%1%0%0%

24%

0%0%0%0%1%0%0%

単位時間毎フレーム数の時間変化

(きちんとキャプチャできているとして)流速(Frame per minute)の時間的変化

単位時間毎フレーム数の時間変化(1日目)

移動中は少ない、待機列中・ガレリア～西あたりが多い

空間の問題か、移動していることに起因するか？

東待機列東中移動中ガレリア～西



やっぱり東ホール移動中が少ないように見える

東待機列東移動中ガレリア～西



1, 2日目に比べると平坦

この山に意味はあるのか？

山？


FPSが混雑率の指標たりうるかどうかは要検証

東待機列(1, 2日目)

単位時間毎フレーム数の時間変化(3日分)

ユニークステーションの増加具合アドレスの学習数の変遷(per minute)

ユニークステーション数の増加具合(1日目)


移動発生時に傾き(?)が変わる

入場ガレリア～西移動



1日目と同じ。ただしもう少し複雑？

やっぱり地理情報が欲しい…

入場ガレリア～西移動


定常的に増加。非常に綺麗。

ユニークステーション数の増加具合(3日分)

ユニークAP数の増加具合(3日分)

ステーション側と基本変わらず

ユニークステーションのキャッシュヒット数学習したアドレスにヒットした数(=前にも居たSTA)

ユニークステーションのキャッシュヒット数学習したアドレスにヒットした数(=前にも居たSTA)

当たり前だが移動時に下がる

ユニークステーションのキャッシュミス数学習したアドレスにヒットしなかった数(=前には居なかったSTA)

ユニークステーションのキャッシュミス数学習したアドレスにヒットしなかった数(=前には居なかったSTA)

ヒット数とは逆に、移動時に上がる

一分ごとに死活監視

now : 現在見えているステーション数

live: 一分前も見えていて今もいるステーション数

old: この一分で消えたステーション数

new: この一分で新しく見えたステーション数

brandnew: この一分で新しく見えた完全に新しいステーション数

無線LANステーション数の時間変化、出入り

無線LANステーション数の時間変化、出入り(1日目)

相変わらず移動を契機に跳ね上がる


1日目同様だが、もうすこし複雑そう


出入りが比較的安定している

再送率の時間的変化

後ろの方で上がってるのは？

他の観点は？

他にどんな観点があるか、有用そうか

このあたりは要検討

アイディア募集

今回の反省/振り返り

次回への改善点

チャネルを複数同時に見れるようにしたい

Android Pcapへの改良, PC利用の検討

定点観測推しで

定点観測キット化

複数チャネルの監視下記のように、やはり1, 6, 11chに集中している

できれば全チャネル見たいが、定期的に監視チャネルを変えるのは筋が良くなさそう主要な1, 6, 11チャネルだけは並列してキャプチャしたいよね Android端末3つ並べて実施?

2013/12/31 09:18

Android Pcapの改良, PC利用

スペアナのロギングをしたい。Chanalyzer for Androidがいつまで経っても出てこないので自作しかない

radiotapヘッダは必要(電波強度, チャネルetc)

FCSが欠けてる、追加すべき

バッテリーが持つならタブレットPCとか？(高い)

定点観測動点観測もそれなりに面白いが

やはり結果が安定しない

不確定要素がおおい

どうにか定点観測できる地点を増やしたい…

地理情報の活用。GPSはいろいろと難しそうだが…

定点観測キットの定式化

今回のでキットに対する一定の知見は得られた(?)

複数チャネルの監視と並行して数を増やしたい

分析周りのスクリプトを増やす

地理情報周りをどうするか…

まとめ

コミケで三日間、パケットキャプチャをしてみた

いくつか分析っぽいことをしてみた

ツールについてはもう少し検討/検証/改造が必要

分析方法ももう少し考えよう

データをいっぱい集めよう

Technology

続・ららら、(無線的に)素敵なComiket Space