-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path04inpractice.re
314 lines (253 loc) · 15.2 KB
/
04inpractice.re
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
= 実際に使ってみた & 解析してみた
//lead{
この章では, これまでに述べたデバイスを用いて実際に集めたフレームの情報を
それっぽく解析・解釈してみた内容をざっと並べます.
//}
== C85
ここでは前回のコミケ(C85)において行ったキャプチャに関するデータを記載します.
=== 計測方法
機材としては以下を用いました.
* 機材: Nexus 7 + AWUS036EW
* キャプチャソフトウェア: Android PCAP
上記デバイスにて, 任意のタイミングでキャプチャを開始します.
観測チャネルは1 (2.412GHz)に固定します.
1, 2日目についてはお買い物ついでの計測のため, 東やら西やらをふらふらと
移動しつつ動点観測っぽいことをしています. 基本的には上記デバイスを鞄に入れた
状態で放置しました. 可能な限りアンテナ部分は外に露出させるように心がけていますが,
そもそも高さが足りなかったり人混みの中だったりするので位置としては微妙です.
3日目についてはサークル参加であったため,
自スペースの机の上に置いて定点観測っぽいことをしています
(西館の"せ-16b").
=== データサイズ・期間
キャプチャデータはそれぞれ以下の通りです.
* 1日目: 2013/12/29 09:49 - 12:06 (動点観測)
** 観測時間: 2時間7分13秒
** 取得フレーム数: 891189フレーム
** pcapファイルサイズ: 163MB
** 平均FPS: 108.2
* 2日目: 2013/12/30 09:52 - 13:39 (動点観測)
** 観測時間: 3時間37分12秒
** 取得フレーム数: 1191454フレーム
** 平均FPS: 91.5
** pcapファイルサイズ: 236MB
* 3日目: 2013/12/31 10:01 - 15:00 (定点観測)
** 観測時間: 4時間48分55秒
** 取得フレーム数: 2070674フレーム
** pcapファイルサイズ: 389MB
** 平均FPS 125.2
上記観測時間は, pcapファイル中の最初のフレームと最後のフレームの時間の差分
を取ったものになります. 平均FPS(Frame Per Second)は, この観測時間で
取得フレーム数を割った数値です.
平均してどれくらいフレームを拾えたかを表す数値になります.
この値は, 測定環境(アンテナの向き, デバイスの場所etc)やデバイスの特性,
観測範囲の空間の電波状況により異なってくるため一概に比較して云々はできませんが
おおよそ毎秒100フレーム程度は拾ってこれるようです.
=== 各種端末数統計
==== AP, 無線LAN端末数
ここでは上記のキャプチャから各種端末数の統計情報等を記載します.
* 1日目
** 無線LAN AP数: 1172
** 無線LAN端末数: 18758
** (参考: 参加者 18万人)
* 2日目
** 無線LAN AP数: 1874
** 無線LAN端末数: 29141
** (参考: 参加者 16万人)
** 3日目
** 無線LAN AP数: 974
** 無線LAN端末数: 18882
** (参考: 参加者 18万人)
無線AP数はBeaconフレームまたはProbe Responseフレームを送信している無線LAN端末
のMACアドレスのユニーク数になります.
無線端末数は, APを含むすべての送信/受信アドレスを数え上げた物になります.
各日とも少なくとも1万後半台以上の無線LAN端末が有効になっており,
C85の参加者が16〜18万人程度とのことなので少なくとも10人に1人程度は
なんらか無線LAN機能が有効になったデバイスを利用している様です.
イベントとしては3日目の参加人数の方が1万人程度多いにもかかわらず
また定点観測という安定した環境であるにも関わらず, AP/端末数ともに
他の日より少なくなっています.
技術島付近という場所の影響なのか, それとも客層の変化によるものなのかは不明です.
==== OUIの分布
次にそれぞれAP/端末ごとに, そのMACアドレスのOUIから
ベンダの分布具合を見てみます.
なお, "UNKNOWN"となっているのはIEEEのOUI Public Listingに, この解析時点で
登録が無かったものを示します.
//table[tbl_c85_dayall_ap_oui][APのOUI Top10のベンダ一覧]{
1日目 2日目 3日目
-------------------------------------
UNKNOWN (39.7%) UNKNOWN (41.1%) UNKNOWN (35.5%)
Huawei Technologies (18.3%) Huawei (19.0%) Huawei (26.4%)
Modacom (3.9%) Modacom (4.3%) Shenzhen Huawei (5.1%)
Ruckus Wireless (3.8%) Shenzhen Huawei (3.6%) NEC AccessTechnica (4.0%)
Shenzhen Huawei (3.1%) AnyDATA Corporation (3.3%) Murata Manufacturing (3.9%)
AnyDATA Corporation (2.8%) Ruckus Wireless (2.8%) LG Electronics (3.7%)
NEC AccessTechnica (2.1%) Murata Manufacturing (2.6%) HTC Corporation (3.7%)
LG Electronics (2.1%) NEC AccessTechnica (2.6%) Modacom (3.6%)
Buffalo Inc (2.0%) LG Electronics (2.6%) AnyDATA Corporation (3.3%)
Panasonic Communications (1.9%) HTC Corporation (2.3%) Ruckus Wireless (1.4%)
//}
UNKNOWNが非常に多いのが不思議ですが, モバイルルータ等でしょうか？
どの日もメンツとしては代わり映えしないようですが, HuaweiがUNKNOWNについで
トップのあたりにいます. Shenzhen Huaweiと登録されているのもこの系列のようなので
UNKNOWNを除けばHuawei製のデバイスがもっとも使われているようです.
=== フレーム種別の統計
ここではキャプチャできたフレームの内訳について見ていきます.
タイプ(Type)で分類するとそれぞれ@<table>{tbl_c85_dayall_type}のようになります.
//table[tbl_c85_dayall_type][全フレームのタイプの割合]{
タイプ 割合(1日目) 割合(2日目) 割合(3日目)
--------------------------------------------------------------------
Management Frame 68.4% 67.2% 74.5%
Control Frame 22.5% 23.3% 15.7%
Data Frame 9.1% 9.4% 9.7%
//}
さらに, その下位にあるサブタイプについても考慮すると
@<table>{tbl_c85_combined_typesubtype_top10}にあるように分類されます.
ここでは各日の
これらのさらなる内訳であるサブタイプについても考慮すると以下の様な結果に
なります. ここでは上位10つのサブタイプについてそれぞれの日付にて記載します.
//table[tbl_c85_combined_typesubtype_top10][各日のフレーム種別 Top 10]{
1日目 2日目 3日目
------------------------------------------------------
Probe Response (31.2%) Probe Response (31.7%) Probe Response (40.8%)
Probe Request (22.3%) Beacon (17.9%) Beacon (20.2%)
Beacon (14.3%) Probe Request (16.9%) Probe Request (22.3%)
ACK (11.0%) ACK (11.0%) ACK (11.0%)
RTS (9.0%) Data (6.1%) RTS (9.0%)
Data (5.8%) RTS (4.7%) Data (5.8%)
Null (2.0%) Block Ack (3.7%) Null (2.0%)
QoS Data (1.2%) CTS (3.3%) QoS Data (1.2%)
CTS (1.1%) QoS Data (1.7%) CTS (1.1%)
Block Ack (1.0%) Null (1.5%) Block Ack (1.0%)
//}
やはりProbe Request/Response, Beaconフレームの比率が高めなのが見て取れる
かと思います. これらは, APや無線LAN端末の数が増えるごとに
何もしなくても増えるものであるためこういった環境では
比較的多くでる傾向にあります.
特にこれらのフレームは低速(1Mbps程度)のレートで送出されるため,
空間上の時間(いわゆるairtime)を長く消費し,
この間基本的に他の無線LAN端末は送信ができなくなるため
データ通信に使える時間が減る→速度低下またはつながらない
といったことにつながります.
=== 時間変化: 単位時間あたりに存在するユニークAP, 無線LAN端末数変化
先に挙げたように, キャプチャデータから802.11フレームの
送信元/送信先アドレスをかき集めると1万を超す無線LAN端末がいそうだというのが
分かりました.
ただしこれは累計値なので, 本当にある瞬間的にキャプチャしているデバイスから
すべてのデバイスが見えたかと言えばそうではないはずです.
ここでは毎分という単位で, どれくらいのAPが見えたかを
@<img>{ts_hist_ap__c85combined}に図示しました.
ここでは, 計測時間の1分ごとにBeaconフレームやProbe Responseフレームを送っていた
無線APの数のユニーク値をプロットしています.
また, このキャプチャデバイスが認識したAPのユニーク数がどのように増えていったかを
@<img>{ts_learn_ap__c85combined}に示します.
//image[ts_hist_ap__c85combined][毎分ごとのユニークAP数の変化 @C85]
//image[ts_learn_ap__c85combined][毎分ごとのユニークAP数の増加具合 @C85]
3日目は定点観測であるということも手伝ってか, 他の日に比べてAP数の変化も
増加具合もかなり安定しています.
上記と同じ事を無線LAN端末全般に対して図示したものが,
@<img>{ts_hist_sta__c85combined}および@<img>{ts_learn_sta__c85combined}
になります.
//image[ts_hist_sta__c85combined][毎分ごとのユニーク無線LAN端末数の変化 @C85]
//image[ts_learn_sta__c85combined][毎分ごとのユニーク無線LAN端末数の増加具合 @C85]
やはり移動が全く無いためか, 3日目の定点観測では他の日に比べて
端末数の変化も増加具合もかなり落ち着いた線を描いています.
特に"ユニークAP/無線LAN端末数の変化"については, ほぼ一定の割合で推移している様に
見受けられます. これがデバイスの受信性能・特性によるものなのか,
それとも人が一定して流入してくることによるものなのかは気になるところです.
== 都内某所
//lead{
これまでC85でのキャプチャ結果は基本的にはかなり"異常な"場所でのものであり
基準としてもうすこし普通の環境のデータが欲しいところです.
ここでは第三章であげたCubieboard2の実証実験もしつつ取ってみたデータを挙げ,
これまでの結果との比較対象としてみます.
//}
=== 計測方法
機材としては以下を用いました.
* 機材: Cubieboard2 + LAN-W300N/U2 (三つ)
* キャプチャソフトウェア: tshark
3つ載っている無線LANデバイスについてはそれぞれ 1, 6, 11チャネルに固定し
キャプチャを行います. 基本的には定点観測として, 適当な位置に放置したのみです.
=== データサイズ・期間
得られたキャプチャデータはそれぞれ以下の通りです.
時間情報は抜け落ちているので便宜上9:00開始としています.
* 共通事項
** 観測時間: 5時間27分12秒
* 1 チャネル
** 取得フレーム数: 3689872フレーム
** pcapngファイルサイズ: 847MB
** 平均FPS: 188
* 6 チャネル
** 取得フレーム数: 2463031フレーム
** pcapngファイルサイズ: 660MB
** 平均FPS: 125
* 11 チャネル
** 取得フレーム数: 2623015フレーム
** pcapngファイルサイズ: 630MB
** 平均FPS: 134
C85に比べて観測時間が長いのでその分データのサイズも大きいですが,
観測方法の違い, デバイスの違い, はたまたairtime的にクリアなのか
FPSではこちらが最大2倍程度となっています.
=== 各種端末統計
C85のデータ同様, AP数と無線LAN端末数のユニーク数をそれぞれのチャネルで
調べると以下の様になります.
* 1 チャネル
** 無線LAN AP数: 69
** 無線LAN端末数: 2443
* 6 チャネル
** 無線LAN AP数: 60
** 無線LAN端末数: 926
* 11 チャネル
** 無線LAN AP数: 55
** 無線LAN端末数: 2090
なお, チャネルをまたいでユニーク数を計算するとAP 160, 無線LAN端末 2940となります.
これは上記データの合計値 AP 184, 無線LAN端末 5459となることから,
いくつかのAPが観測期間中にチャネルを変えるオペレーションを行っていたことがうかがえます.
端末数に関しては, 無線LANクライアントは基本的にAPを探すためにチャネルを片端から
舐めてProbe Request等を送信する挙動を取るので大きく差が出ることは折り込み済みです
@<fn>{apple_oui}.
//footnote[apple_oui][また昨今ではMAC Address Randomizationも導入されようとしておりこの値にも意味が無くなるかもしれません]
=== フレーム種別統計
//table[tbl_wlancombined_type][全フレームのタイプの割合]{
タイプ 1 チャネル 6 チャネル 11 チャネル
--------------------------------------------------------------------
Management Frame 72.0% 82.0% 81.3%
Control Frame 13.2% 7.9% 11.2%
Data Frame 14.7% 10.1% 7.5%
//}
Managementフレームの割合はC85での結果と同じく(あるいはさらに)高いままですが,
ControlフレームとDataフレームの比率が一部逆転しています.
//table[tbl_wlancombined_typesubtype_top10][各チャネルでのフレーム種別 Top 10]{
1 チャネル 6 チャネル 11チャネル
------------------------------------------------------
Beacon (64.3%) Beacon (74.3%) Beacon (69.6%)
Data (10.6%) ACK (5.8%) Probe Response (8.3%)
ACK (7.1%) Data (5.4%) ACK (5.7%)
Probe Response (5.2%) Probe Response (4.0%) Data (4.7%)
Probe Request (2.5%) QoS Data (3.9%) Probe Request (3.3%)
CTS (2.2%) Probe Request (3.6%) RTS (3.1%)
QoS Data (2.0%) RTS (1.1%) CTS (1.5%)
RTS (1.9%) CTS (0.6%) QoS Data (1.4%)
Null (1.9%) Null (0.5%) Null (0.9%)
Block ACK (1.6%) Null QoS Data (0.2%) Null QoS Data (0.6%)
//}
サブタイプ上の割合としても, C85側(@<table>{tbl_c85_combined_typesubtype_top10})でのそれと比べて
Probe Responseの割合が減り代わりにDataフレームが上位に食い込むことができています.
逆にBeaconフレームはかなりの割合を食うようになりました. C85では並んで20%程度でしたが,
こちらでは平均70%程度となっています.
=== 時間変化: 単位時間あたりに存在するユニークAP, 無線LAN端末数変化
//image[ts_hist_ap__1235_wlancombined][毎分ごとのユニークAP数の変化 @某所]
//image[ts_learn_ap__wlancombined][毎分ごとのユニークAP数の増加具合 @某所]
ユニークAP数の変化のグラフにて面白いのは, @<img>{ts_hist_ap__1235_wlancombined}と
C85でのそれ(@<img>{ts_hist_ap__c85combined})の平均した毎分のユニークAP数がほぼ同じであることです.
APの参入・離脱のモデルが異なるため一概に比較が難しいところはありますが
一分前のAP群と今のAP群との比較などにより流量により同じになっているのか
またはなんらか別の要員があるのかについては調べてみたいところです.
//image[ts_hist_sta__1235_wlancombined][毎分ごとのユニーク無線LAN端末数の変化 @某所]
//image[ts_learn_sta__wlancombined][毎分ごとのユニーク無線LAN端末数の変化 @某所]
#@# フレームレートも使ってみる
== そしてC86...
2014/08, この薄い本が発行されているであろうC86には
cubieboard2とraspberry piの2つのデバイスを持ち込んでいます.
前者で2.4GHz帯の1, 6, 11チャネル, 後者で5GHz帯の36, 40チャネルでの
キャプチャを行っています. C87あたりではこれらの観測結果について
何らかご紹介できればと考えています.