Comments

イベント無線LANでのチャネル使用率調査

概要

いつもやっている、イベント会場でのパケットキャプチャに加えてここ最近チャネルごとの使用率の収集も始めました。

計測対象

今回、計測対象にしたのは以下の4イベント(7回)。大抵、鞄の中にデバイスを入れて移動しつつパケットキャプチャを行っています。設置場所を確保できた場合、定点観測的に収集をしています。

イベント	日	場所	固定?
なにか	2015/08/02	どこか	Y
コミケ (C88)	2015/08/14	東京ビッグサイトホール(東、西)	N
	2015/08/15	東京ビッグサイトホール(東、西)	N
	2015/08/16	東京ビッグサイトホール(東)	Y
YAPC::Asia Tokyo 2015	2015/08/14	東京ビッグサイト会議棟	N
	2015/08/14	東京ビッグサイト会議棟	N
コミティア113	2015/08/30	東京ビッグサイトホール(2,3)	N

チャネル利用率のヒートマップ

5分毎に区切って、チャネルごとにヒートマップ化したものを並べてみる。

2015/08/02 あたりのイベント

2015-08-02-util

コミケ (C88)

コミケでは、1日目および2日目は一般参加、三日目のみサークル参加だったため東 P-18b にて定点観測を実施。動的観測の場合、列に並んだあとに観測開始し買い物が終わってビッグサイトから出て国際展示場に行くまでの間のどこかで停止している。

列に並んだ時間 (西)
- 1日目: 10:15頃
- 2日目: 10:10頃
ビッグサイトを出た時間
- 1日目: 12:50頃
- 2日目: 11:10頃
彷徨ったルート (覚えてる範囲で)
- 1日目: 西(入場) → 東123→東456→西(退場)
- 2日目: 西(入場) → 東123→東456→西(ホール)→西(退場)

1日目 (2015/08/14)

2015-08-14-util

2日目 (2015/08/15)

2015-08-15-util

3日目 (2015/08/16)

2015-08-16-util

YAPC::Asia Tokyo 2015

こちらは CONBU チーム (いわゆる Wi-Fi 班)として参加したときのもの. 作業時に邪魔にならない場合、ショルダーバッグにデバイスを入れて彷徨うようにはしていました. が、バックヤードに起きっぱなしの時間も大分あったため有為なデータが取れていない可能性は多々ありそう。

1日目 (2015/08/21)

2015-08-21-util

2日目 (2015/08/22)

2015-08-22-util

コミティア113 (2015/08/30)

2015-08-22-util

考察

何となく移動が見える
- 特にビッグサイト(ホール)
  - 5GHz帯 36、48、64、100 chの濃淡
    - ホールから抜けたかどうかが判断できそう
  - C88 1日目、2日目の移動に連動していそう?
- YAPCの結果を見ても、場所変化には連動している模様
- Wi-Fiをオフされた時も同様の状況になりうるので一概に逆は言えないが….
2.4GHz帯側の分布具合
- 8/2 と YAPCのそれはだいぶ綺麗にみえる
  - 1、6、11 chの中央とそれらの両隣が濃く出ている
  - これらのイベントでは、会場内無線LANのコントロールが提供側でそこそこなされていたため？
  - 野良APまたはクライアントの絶対数の有無?
- “人の密集度 == 2.4GHz帯側の濃度” という仮説
  - C88 1日目、2日目の2.4GHz と 5GHz の比較より
  - ホールから出て 5GHz 帯側が明らかに薄くなっていて、2.4GHz帯側はそこまで落ちない時間がある
    - まだ列に並んでると思しき時間
    - ホール間移動と思しき時間
    - 帰途についてビッグサイトを出たと思しき時間
  - モバイルルータの影響？

実装

以下、軽く実装についてメモ

情報源として用いる情報

チャネル利用率の算出には iw コマンドの以下のオプションを用いました。

% iw wlan0 survey dump

survey dumpでは以下の様にそのチャネルに移動してからのアクティブ時間(=移動後の経過時間)とビジーだった時間が得られます。

Survey data from wlan0
        frequency:                      2412 MHz [in use]
        noise:                          -83 dBm
        channel active time:            35900 ms
        channel busy time:              24814 ms
        channel transmit time:          0 ms

今回用いたデバイス(WLP-UC-AG300, チップはRT2870)の場合、この値はソースコード上の以下の部分で計算しています。 https://github.com/torvalds/linux/blob/master/drivers/net/wireless/rt2x00/rt2800lib.c#L7984

なおここでの”ビジー”は、送受信またはノイズによりこれらがストップしていたチップの動作時間であり、以下の様な関係式がなりたちます。

channel busy time   = receive time + transmit time + other time
channel active time = busy time + idle time

チップによっては transmit time の他に receive time も個別に取り出せるので other つまり 802.11 以外の電波により送受信ができていなかった時間も取れるのですが今回は対象外としました。

tochkad での記録

このように取れるチャネル利用率を、パケットキャプチャデバイスの主観部分を担う tochkad のチャネル遷移部分で取得するようにしました。

athsurvey.rb

tochkadは0.5秒毎にチャネル遷移するので大分短い時間ではありますが、ログ上に以下の様に utilization (利用率)が載るようになります。

[2015-08-02 15:20:43 +0900]     DEBUG: channel moved to 11 from 10 (dur=6510、size=481767780、walk=6062、utilization=59.68 uch=10)

この利用率は tochka デバイスについている LCD ディスプレイ (tochka-miniui) にも出すようにしています (赤枠部分)

tochka-miniui

802.11, research, tech

Comments

SIGCOMM2015: Large-scale Measurements of Wireless Network Behavior を読む

概要

リンク: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p153.pdf

SIGCOMM ‘15で発表された論文。Cisco Merakiの人たちが著者。
Merakiはいわゆるクラウド型無線LANコントローラとAPのセットのサービス。
自社のサービスを展開している中で収集されたデータのオーバービュー的な文章。

読んだモチベーション

Wireless Network という題に惹かれて
お仕事で似た様なことやってるため

内容

落合先生フォーマットに従って並べてみる

どんなもの？

Merakiのサービスを提供するに当たって収集したデータの分析を行った
- 2万台のMeraki AP, 2万個のネットワーク, 5百万クライアント/week の規模
- これらのネットワークにぶら下がる数百万のデバイスの様々な情報が自社のDBに溜まっている
  - ネットワークに所属するデバイスたち: AP, クライアント端末(ノートPC, スマホ e.t.c), スイッチ, ルータなど
  - 情報: 接続断のイベント, 通信先など
  - Meraki(のサービス側)は, いわゆる無線LANコントローラなのでこれらの情報を常にpolling/収集している
これだけ規模が大きく, 期間も長いと”無線LANネットワークのトレンド”的なものが見えてくる
- 電波的な傾向
  - 他のAP or 802.11以外の干渉
- 規格上の傾向
  - 2.4 or 5GHz帯への偏り
  - 802.11g, a, n, acの偏り(利用率の変化)
  - チャネル幅の遷移
  - ストリーム数の遷移
- クライアントの傾向
  - OSのバリエーション
  - 信号強度
- ネットワークの傾向
  - いわゆる普通のトラフィック分析
  - アプリケーション利用率

先行研究と比べて何がすごい？何が違う？

まず数
- Gemberら(当該研究者が所属する大学ネットワークや施設のネットワークが対象)、Rodrigら(カンファレンスネットワークが対象)等、干渉の計測やネットワークトラフィックの分析を行った研究は存在する。この論文では、さらに大規模なユーザベースでの分析を行っている。
- Hotspotを対象にそこそこの規模で行った例としては Ghoshら(243000デバイス)、Google (500AP, 30000クライアント)等があるがこれらはあくまでHotspot向けであり、この論文(およびMerakiのサービス)が対象としているオフィス/キャンパスユースではない
計測期間の長さ (とそこから来るデータ量)
- おもに他の研究ではショットないし1年内程度のスパンで行ったものが主
  - 短いスパンであれば、個々の技術・計測に関する分析を行った既存研究は多種存在する
  - 干渉の定性的分析や規格の技術的妥当性の検証という観点で
- この論文では5年程度のスパンで見ている
  - “トレンド”という点に着目できる内容になっている
  - さらに取得した、サービスの継続にあたって重要な無線LANインフラ(!=無線LAN only)の情報を分析対象としている

技術の手法とかキモはどこ？

サービスのプロダクション環境に当該情報収集系を組み込んだところ
- いわゆる”実用”の場でのデータが取れる
- お客さんのバリエーション == “実用”の度合いに直結する
観点として「サービスの継続性」のための情報収集に特化しているところ
- 個々の規格・技術の妥当性検証というよりは、その現れ方・利用され方の観測が主

どうやって有効だと検証した？

Evaluationとして有効性を示す文章はない
強いて言えば実環境でこんな感じのデータが取れたぜ！という報告に近い?

議論はある？

(TBD)

次に読むべき論文は？

GamberらのとGoogleのやつ？
- 1. Gember, A. Anand, and A. Akella. A comparative study of handheld and non-handheld traffic in campus wi-fi networks.
- 1. Afanasyev, T. Chen, G. M. Voelker, and A. C. Snoeren. Usage patterns in an urban wifi network
Senらの”Cspy: finding the best quality channel without probing”も気になる
- 1. Sen, B. Radunovic, J. Lee, and K.-H. Kim. Cspy: finding the best quality channel without probing.

report, tech

Comments

YAPC2015 に CONBU プロジェクトメンバとして参加してきました

掲題の通り YAPC::Asia Tokyo 2015 に CONBU スタッフ (いわゆる Wi-Fi 班)として参加してきました. 今年で最後の yapcasia だそうですが, 今回が初参加なので最初で最後になってしまいました. なおずっとpingの結果と, スペアナの画面だけ見ていたので内容まできちんと聞き入ってたセッションがありません….

CONBUの華々しい活動については, 以下をご覧頂くと良いかと思います.

感想

正直なところ, ネットワーク周りに首ったけになっていた結果 Perl のカンファレンスに参加したというよりお祭りに参加してネットワーク敷設のお手伝いしてきた, という印象の方が強かったです. Perl は10年ぐらいまえに CGI で遊んでた頃に書いたっきり全く触ってなかったので perl mongers に取り囲まれてぼっこぼこにされるんじゃないかと震えてたのですが, ruby やら go やら思ったより多様性に溢れていたのが印象的でした. なおちらっと Larry Wall の実物は見ることができました.

YAPCらしきことをつぶやいてたログ

なおこんな感じのアロハ pic.twitter.com/f1VfP6BJZW
— えぬかね@C88ありがとうございました (@n_kane) 2015, 8月 20

コミケ6日目 (@ 東京国際展示場 (東京ビッグサイト/Tokyo Big Sight) - @t_bigsight in Koto, 東京都) https://t.co/9s894TJKVj pic.twitter.com/lHRKGaVziW
— えぬかね@C88ありがとうございました (@n_kane) 2015, 8月 21

どこまでベラベラしゃべって良いのか判断ついてなかったので, あんまりないね…

聞いてたセッション

かろうじて片耳で聞いてたセッションの一覧はこんな感じ

TBD by Matz
- streemのお話からセッションに潜入.
うっかりをなくす技術 by karupanerura
Discover the Microsoft Azure by Tatsuro Hisamori
- 1日140円から始めるIoTデータ分析・可視化はちょっと読んでおきたい
データ分析基盤を支える技術 by repeatedly
- ちょうど後述する「パケット集め」で集めたデータどうするかーという段階だったので一番気になるセッションではありました
カンファレンスネットワークの作り方 by CONBU
- みんな聞きにきたよね?

Wi-Fi的にはD, Eが激戦区だったのでそのあたりには居たのですがセッションの内容まで覚えてるのはこの辺りの模様…

なぜか CONBU は LT で設営デモもやりました

どこかに映ってる, ヒゲダルマを探そう.

CONBUの設営、すばらしい！ #yapcasia pic.twitter.com/NNn4sRdc4a
— 馮　富久/FUON Tomihisa (@tomihisa) 2015, 8月 22

突然目の前に無線APが生えてきた #yapcasia pic.twitter.com/UWcSzvRv08
— ぷりんたいは求職中です、 (@spacepro_be) 2015, 8月 22

@n_kane @kichi_robo 未公開シーンです、ご査収ください pic.twitter.com/mcF5xBafUJ
— ぷりんたいは求職中です、 (@spacepro_be) 2015, 8月 22

パケット集め

一週間前にあったコミケでも持ち込んだ下記のデバイスを YAPC でも持ち込んで, バッグのなかに入れつつうろうろしてました. (下記はコミケの時の写真)

あとスペースの裏側で、今日も今日とて無線LAN(802.11)のパケットキャプチャしてます。今回書きたかった&次回書きたい、キャプチャデバイス→embulk→DB→解析系の一連の流れ、に食わせる最初の一歩の子になります。 pic.twitter.com/TeMvyv3whl
— えぬかね@C88ありがとうございました (@n_kane) 2015, 8月 16

最終的に, 単純なpcapngのデータサイズとしては 3GBほど, フレーム数にして 10M フレーム, となかなか良い感じにあつまりました. 会場Wi-Fi, 日中は定常的に 100Mbps ほど出ていたとのことでフレーム飛び交いまくってたはずなのでやっぱり集まりが良いようです.

朝方postgreにぶち込み終わってたはずのC88とYAPC2015で集めたフレームたちのヘッダデータ、良い感じの分量だ。さすがにYAPCでは通信が盛んだったのか二日分の割にコミケのそれより倍多い。 pic.twitter.com/9wvHk3nrDV
— えぬかね@C88ありがとうございました (@n_kane) 2015, 8月 25

終わりに

最初で最後の YAPC::Asia Tokyo にネットワークスタッフとして参加, そしてそっちに夢中になっててあんまり本編を聞いていないとかどういうこっちゃという感じではありますが, それはそうとしてそれなりに楽しまさせていただきました. 関係者の皆様ありがとうございました.

802.11, rf, tech

Comments

貧乏人でもスペアナがしたい!

貧乏人でもスペアナがしたい!(掲題ママ)

新品を買うと, 数十万〜数百万だし, ヤフオク等の中古品でも明らかなジャンク品でないものに限ったとしても十〜数十万ぐらいは行ってしまう.

やりたいことができて, こわしても気落ちしない程度のモノが欲しいので探してみたメモ.

やりたいことベースでのおおよその要件は以下の通り (貧乏人にしては盛りすぎだ!生意気だ!等のコメントはNO)

(MUST) 無線LANの周波数帯がカバーできること
- 2.4 & 5GHz帯
(MUST) PCと連携できること
- (SHOULD) 外部のスクリプト等で扱える形式でデータがエクスポートできること
- (MAY) あるいは, 独自形式でもかまわないが仕様が公開されていること
(MUST) 数十万円後半は絶対にNO
- 10〜20万ぐらいが限度
(MAY) RBW と sweeptimeの両立がそこそこ成り立つこと
- (MAY) できれば20/40MHzスパンに対して200〜300kHzのRBWで数百ms程度が望ましい (秒はかからない程度であれば)
(MAY) できれば普通のスペアナと同じような汎用性
- スペアナのお勉強用に使えること
(MAY) Mac向けのアプリがあること
- (MAY) あるいはUNIX系からアクセス可能なインタフェース(ライブラリ/API etc)が用意されていること
(MAY) USBバスパワーで動くこと
(MAY) 携帯可能な電源仕様, 形状, 重さであること

おおよそ2つの側面があって, きちんとしたスペアナ買ってお勉強したいというのと, 今までやってきている無線LANキャプチャに織り交ぜたいという2つの方向からの要求が混ざっている. 分けた方がいいような気はする.

候補になりそうな人たち

中古のスペアナをヤフオクで探すのは継続するとして, ハンディに使えそうな子達.

Giga ST
RF Explorer 6G Combo
Aaronia AG
- SPECTRAN HF-6060V4
- SPECTRAN HF-6060V4 X
Metageek WiSpy DBx
Signal Hound
- USB-SA124B
- BB60C
Tektronix RSA306

機種	お値段	周波数レンジ	RBW	スイープ時間	アプリ対応OS	export可?
GigaSt v5c	29,000 (税, 送料込み)	3 - 12000MHz	15/30/180 KHz	500ms? (SPAN:100MHz, RBW:180KHz)	Windows	形式不明
RF Explorer 6G Combo	43,800 (税込み)	15 - 2700MHz, 4850 - 6100 MHz	2.6 - 812 kHz	200ms? (Span: 60MHz, 600KHz)	Windows, Mac(?)	XML/CSV
SPECTRAN HF-6060V4	€999.95 (129,384)	10MHz - 6GHz	3kHz - 50MHz	200ms (Span: 20MHz, RBW: 300kHz)	Windows, Linux, Mac	CSV
SPECTRAN HF-6060V4 X	€999.95 (129,384)	10MHz - 6GHz	3kHz - 50MHz	200ms (Span: 20MHz, RBW: 300kHz)	Windows, Linux, Mac	CSV
WiSpy DBx	$1,149 (136,834)	2.4GHz帯, 5GHz帯	500ms (Span: 95MHz, RBW: 333KHz)	500ms or 1s ?	Windows, Mac	sqlite DB
USB-SA124B	$1,995 (238,386)	100kHz - 12.4GHz	100Hz - 250KHz, 6MHz		Windows	?
BB60C	$2,879 (342,860)	9kHz - 6GHz	10khz	24GHz/sec	Windows	?
RSA306	434,000	9kHz - 6.2GHz	10Hz - 10MHz	100us (Span: 400MHz, RBW: 300KHz)	Windows	CSV

諸々の前提

とりあえず無線LANターゲットなので, スパンとして20/40/80/160MHzがありうる
- OFDMの各キャリアは312.5KHz間隔
RBWと掃引時間の関係: sweeptime [s] = (k * span [Hz]) / (RBW [Hz])²
- 掃引時間はRBWの二乗に反比例
- 掃引時間は周波数スパンに比例

候補

GigaSt v5c

参考
- http://www.wa.commufa.jp/gigast/GigaSt5/GigaSt-v5.html
- https://www.youtube.com/watch?v=3vLZrA0e8EY
Pros
- 安い! (送料込みで3万円以下)
- USBバスパワー駆動
- 内部的にはシリアル(VCP) & コントロール等々のドキュメントはそろってるので他OSでも触るのは簡単そう
Cons
- ケースはないので自分で用意
- 「グラフデータ保存機能」でどんな形式がサポートされてるか
- 注文ウィンドウがよく分からない (受付してない時期がある?)

RF Explorer 6G Combo / WiFi Combo

参考
- http://rfexplorer.com/combo-specs/
- https://www.youtube.com/watch?v=3ZhdcUJanCI
Pros
- コンパクト
- そこそこお安い(5万内)
- 千石電商でも売っているので手には入れやすい
- デバイスにLCDがついてる
- バッテリー付き(16時間+ぐらいは動くらしい)
- こちらも内部的にはシリアルっぽいのでコマンド叩けばいろいろ遊べる (rfexplorer)
Cons
- 2700MHz〜4850MHzの間は計測不可
  - とはいっても今のところ使い道はない
- 基本となるアプリ(touchstone)は無料だけど, 一部のアプリが有料 ($49)
  - 有料版(PRO)でないとxml/csvへのエクスポート機能がない

Aaronia SPECTRAN HF-6060V4 / HF-6060V4 X

参考
- SPECTRAN HF-6060 V4
- SPECTRAN HF-6060 V4 X

V4はいわゆるハンドヘルド版で, V4 Xがデスクトップ向け.

Pros
- MCSなるアプリが無料, Win/Mac/Linuxをそれぞれサポートしてる
- V4ハンドヘルド版は単体で動作可能
- サポートしてる周波数帯は基本的に連続 (どこかで途切れてる可能性はあるが)
- 悪くない価格 (11万程度)
Cons
- V4 XがUSBバスパワーだけでは動かない. 動いたら完璧だったのに…
  - モバイルバッテリーでは無理だろうが, DCなバッテリー + 電源ケーブル調達でなんとかなりそうではある
- V4ハンドヘルド版の動作時間は?
- V4とV4 Xの機能面での差は?
  - LCD, ジョグダイヤルの有無
  - 付属アンテナ:
  - HyperLOG EMC directional LogPer antenna: 7060 vs なし
  - OmniLOG 90200 radial isotropic antenna: なし vs あり
  - Xのみ: マーカの数unlimited, 複数デバイス操作可, スイープポイント無限等々
    - Xの方にだけPRO版ソフト?とやらが付いてくるらしいが?

WiSpy DBx

参考
- WiSpy

「無線LAN & スペアナ」でググると一番最初に出てくるデファクトスタンダード品みたいなもの.

Pros
- 無線LANに特化
  - AP(SSID)一覧との紐付けが標準で存在している
  - 「チャネル:周波数」の変換
- Macのアプリがある (Channalyzer)
- kismetが出してるspectoolsを使えばLinuxでも動きそう
Cons
- スペアナと見たときに, 細かいことがあまりできない
  - 細かいパラメータがいじれない
  - 無線LAN以外にはあまり使えなさそう
    - 無線LAN特化のスペアナという立ち位置
    - 現状無線LAN以外に使う予定はないが, 勉強用なので諸々のパラメータは弄りたい
  - 5GHz帯は細かくチャネルごとに見れない
    - 2.4GHz帯はチャネル毎に見れる
- その割には値段が高い (13万ぐらい)

スイープの性能については以下の通り. 見てる幅により固定になっている.

2.4GHz 全体
- Span: 95.310MHz ( 2400 - 2495 MHz )
- RBW: 333.3 KHz
- スイープ時間: 500ms?
2.4GHz各チャネル (例としてチャネル 1)
- Span: 424MHz ( 2400 - 2424 MHz )
- RBW: 100kHz
- スイープ時間: 500ms?
5GHz
- Span: 676.7 MHz ( 5160 - 5836 MHz )
- RBW: 150.0 KHz
- スイープ時間: 1s?

Signal Hound USB-SA124B / BB60C

参考
Pros
- スぺアナというよりはHackRFとかUSRPみたいなSDRデバイス + スペアナができるアプリという感じ
- BB60Cに至っては24GHz/sec sweep speed (>= 10kHz RBW)
Cons
- お値段は微妙 (RSA306に手が届きそうな値段)
- スペアナというよりSDR. これかうならHackRF買った方がよさそうな気はする.

Tektronix RSA306

RSA306型USBスペクトラム・アナライザ

Tektronixが出した「USBリアルタイムスペクトラムアナライザ」

Pros
- 反応めっちゃはやい
  - 40MHz幅内ならRBW 120KHzぐらいまでならだいぶぬるぬる表示する
- ソフトはタダ (基本部分は, という条件付きだが)
- USB3.0ポート一つで制御・電源供給
Cons
- お値段
  - とはいえこの性能比で考えれば破格. 単純に予算の問題

802.11, tech

Comments

Chokaigi 2015 Wi-Fiみてきた

ニコニコ超会議2015で Free Wi-Fi が提供されている、とのことだったのでどんな感じなのか偵察に行くついでにいつもの如くパケットあつめてデータをまとめてみた.

tech

Comments

2015-02-23 Released Embulk-input-pcapng-files 0.1.0

pcapngファイルを読み込むembulk inputプラグインの新しいのをリリースしました.

embulk 0.4.X系ではプラグイン体系が0.3.X系のそれとは異なっているため, これまで晒していたembulk-plugin-input-pcapng-files が動作しません. これを修正したものが上記になります.

使い方自体は変わらず, 以下の様なconfig.ymlを書いて実行すると…

exec: {}
in:
  type: pcapng_files
  paths: [ /Users/enukane/Desktop/emtestpcap/ ]
  threads: 2
  schema:
    - { name: frame.number,                 type: long }
    - { name: frame.time_epoch,             type: long }
    - { name: frame.len,                    type: long }
    - { name: radiotap.length,              type: long }
    - { name: radiotap.mactime,             type: long }
    - { name: radiotap.flags.preamble,      type: long }
    - { name: radiotap.flags.wep,           type: long }
    - { name: radiotap.flags.fcs,           type: long }
    - { name: radiotap.flags.shortgi,       type: long }
    - { name: radiotap.datarate,            type: long }
    - { name: radiotap.channel.freq,        type: long }
    - { name: radiotap.channel.type.ofdm,   type: long }
    - { name: radiotap.dbm_antsignal,       type: long }
    - { name: radiotap.dbm_antnoise,        type: long }
    - { name: radiotap.xchannel,            type: long }
    - { name: radiotap.xchannel.freq,       type: long }
    - { name: radiotap.xchannel.type.ofdm,  type: long }
    - { name: radiotap.mcs.gi,              type: long }
    - { name: radiotap.mcs.bw,              type: long }
    - { name: radiotap.mcs.index,           type: long }
    - { name: wlan.fc.type_subtype,         type: long }
    - { name: wlan.ta,                      type: string }
    - { name: wlan.ra,                      type: string }
    - { name: wlan.sa,                      type: string }
    - { name: wlan.da,                      type: string }
out:
  type: mysql
  host: localhost
  user: testuser
  password: testpassword
  database: testdb
  table: testtb
  mode: insert

こんな感じにoutput先 (今回の場合はMySQL) にデータをはき出してくれます.

pcapng-mysql

memo, network, tech

Comments

2015-02-12 DS-Liteいれてみた

追記

2015/02/13 「速度計測その2」を追加
2015/02/16 「速度計測その3」を追加

はじめに

新居でのフレッツv6オプションおよび IIJmio FiberAccess/NF の準備ができたので DS-Liteで IPv4での疎通性を確保してみた. が, ちょいと速度面で問題?があったのでメモ.

設定

設定は以下を参照. フィルタ周りの設定やIPv4 PPPoe周りを継ぎ足してほぼそのままで導入.

SEIL/x86でDS-Lite

動作確認

tracerouteを取ってみるとこんな感じに transix.jp を通って IPv4インターネットに出て行けてることが確認できたら完了. traceroute-dslite

なお普通にIPv4 PPPoE経由でいくとこんな感じになる. traceroute-iijmio

速度計測

問題は速度で, 以下の様な三者間で速度を測ってみるとどうにも DS-Lite 経由の iperf の結果が芳しくない.

dslitevspppoe

経由	ISPまたは事業者	対戦表	速度(Mbps)	備考
???	sakura internet?	1	87.2	VPS側の速度計測用
DS-Lite	Multifeed(transix)	2	46.5
DS-Lite	Multifeed(transix)	3	43.5
IPv4 PPPoE	IIJmio	2	87.9
IPv4 PPPoE	IIJmio	3	73.7
IPv4 PPPoE	Interlink	2	88.6
IPv4 PPPoE	Interlink	3	69.4

なお上流はフレッツ光マンションタイプ・ミニ(VDSL方式)なので,最大100Mbps
ルータにはSEIL/X1を利用
常にsakura VPS側がiperf server
- 1の場合は, 東京第二側をserverに
めんどうなので一発勝負. 5回平均や最大値採取はせず

おおよそIIJmio側もInterlink側も70〜80Mbps程度は出ているように見受けられる. 一方, DS-Liteを通すとなぜか40〜50Mbpsに下がる模様.

さて, なんででしょう.

速度計測その2

上記速度計測では, LAN内からはiperf clientとしてしか通信していなかったので, ここではiperf3 (ver 3.0.11)のReverseモードを使って, 上り下り両方を測ってみる. なお, 上記速度計測とは以下の違いがある.

今度は MacBookAir + Thunderbolt Ethernet Adapterをiperf clientとして利用
- 若干速くなってる
IIJmioとinterlinkには速度差はあまりないのでinterlink側経由の速度は省略

経由	ISPまたは事業者	対戦表	向き	速度(Mbps): sender	速度(Mbps): receiver
DS-Lite	Multifeed(transix)	2	UP	51.5	51.2
DS-Lite	Multifeed(transix)	2	DOWN	90.4	89.9
DS-Lite	Multifeed(transix)	3	UP	53.5	53.1
DS-Lite	Multifeed(transix)	3	DOWN	90.9	90.4
IPv4 PPPoE	IIJmio	2	UP	93.8	93.8
IPv4 PPPoE	IIJmio	2	DOWN	94.1	93.4
IPv4 PPPoE	IIJmio	3	UP	87.3	86.3
IPv4 PPPoE	IIJmio	3	DOWN	88.6	87.5

iperf3はクライアント側からサーバ側に向けてトラフィックを出す
“-R”オプションで逆方向になる
このため, “-R”なしがUP, ”-R”ありがDOWN

DS-LiteのUP方向が妙に抑えられているようだ. DOWN方向は普通に速度が出ている.

速度計測その3

“option ipv6 avoid-path-mtu-discovery on|off”を切り替えてみる. 対戦表は2のみ.

経由	ISPまたは事業者	avoid-path-mtu-discovery	向き	速度(Mbps): sender	速度(Mbps): receiver
DS-Lite	Multifeed(transix)	default	UP	50.4	50.2
DS-Lite	Multifeed(transix)	default	DOWN	90.2	89.8
DS-Lite	Multifeed(transix)	off	UP	75.0	74.9
DS-Lite	Multifeed(transix)	off	DOWN	90.5	90.0
DS-Lite	Multifeed(transix)	on	UP	52.0	51.7
DS-Lite	Multifeed(transix)	on	DOWN	90.7	90.4
IPv4 PPPoE	IIJmio	X	UP	93.7	93.7
IPv4 PPPoE	IIJmio	X	DOWN	93.4	92.5

offにすると少し良くなるようだ.

tech

Comments

2015-01-28 Embulk-plugin-input-pcapng-files書いた

追記 (2015/01/29 20:03)

ver 0.0.2切った. ファイルのソート周りはまだ直してない.

https://rubygems.org/gems/embulk-plugin-input-pcapng-files

追記 (2015/01/29 19:49)

手元で動作確認してたらいつの間にか次のバージョンのembulkがリリースされてた. おかしいぞ…さっきのpullreqで入れてもらったワークアラウンド試し始めたばっかりなのに…(もう不要になった)

https://twitter.com/frsyuki/status/560750747608817665

追記 (2015/01/29 19:38)

frsyuki先生から後ろ方のてきとーなメモに対する, 大変丁寧なコメントを頂けた. なるほどなるほど.

https://gist.github.com/frsyuki/dcfb30690fd453542f45

ついでにいろいろと手直しして頂いて感謝感謝

はじめに

前々からやっているコミケその他イベントでの無線LAN解析(※)に良い感じに使えそうなので pcapngファイルからの入力を取れる “embulk-plugin-input-pcapng-files” なるプラグインを書いてみました.

中身はまんまtshark呼んでるだけですが, 抽出条件をコンフィグに書けたり出力先を柔軟に変更可能だったりと embulkのよさげなところを活かせそうなのが良い感じです.

今までは集めた多量のpcapngファイルを, ひとつひとつ真心()込めてスクリプトに食わせてたのでこれを期に自動化の流れが造れるとベター. またそこまで行かなくともこれまでに溜め込んだpcapngファイルの再掘り起こしが容易になるのでそれだけでも良い感じです.

正直pcapngをこんな感じに触りたい人いない気がするので, 誰にも使ってもらえない感…

使い方

コンフィグファイルはこんな感じになります. いわゆるguessはできないので手打ちで全部書く必要があります.

exec: {}
in:
  type: pcapng_files
  paths: [/Users/enukane/Desktop/emtestpcap/, /tmp]
  threads: 3
  schema:
    - { name: frame.time_epoch, type: long }
    - { name: frame.len, type: long }
    - { name: wlan.ta, type: string }
    - { name: wlan.ra, type: string }
out: {type: stdout}

typeにはpcapng_filesを指定します
pathsには, 処理したいpcapngファイルが入ったディレクトリを配列で指定します
threadsは, 並列度を指定します
- 上記paths内で見つかったpcapngファイルたちをこのthreadsの数に分配して並行に処理がなされる, はず
- ちゃんと動いてるかは未確認…
schemaにはpcapng中の抽出したいフィールド名(name)と変換先の型(type)を指定します
- フィールド名は, wireshark/tsharkで -e オプションのfilterとして使っている名前が指定できます
- 型は今のところstringかlongのみ

これをpreviewコマンドで指定してみるとこんな感じ

enukane@glenda-lairなう（´・ω・｀）つ ~/Sources/embulk-test % java -jar embulk.jar preview config.yml
+-------------------------------------------------+-----------------------+----------------+-------------------+-------------------+
|                                     path:string | frame.time_epoch:long | frame.len:long |    wlan.ta:string |    wlan.ra:string |
+-------------------------------------------------+-----------------------+----------------+-------------------+-------------------+
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             45 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             39 |                   | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             57 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             45 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             39 |                   | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |            146 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             57 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |            151 | c4:7d:4f:56:e5:1c | 33:33:00:01:00:03 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |            131 | c4:7d:4f:56:e5:1c | 01:00:5e:00:00:fc |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |            283 | c4:7d:4f:56:e5:18 | ff:ff:ff:ff:ff:ff |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             45 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             39 |                   | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |            146 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test1.pcapng |         1,413,615,217 |             57 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             45 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             39 |                   | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             57 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             45 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             39 |                   | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |            146 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             57 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |            151 | c4:7d:4f:56:e5:1c | 33:33:00:01:00:03 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |            131 | c4:7d:4f:56:e5:1c | 01:00:5e:00:00:fc |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |            283 | c4:7d:4f:56:e5:18 | ff:ff:ff:ff:ff:ff |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             45 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             39 |                   | c4:7d:4f:56:e5:19 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |            146 | c4:7d:4f:56:e5:19 | 20:c9:d0:d8:37:31 |
| /Users/enukane/Desktop/emtestpcap//test2.pcapng |         1,413,615,217 |             57 | 20:c9:d0:d8:37:31 | c4:7d:4f:56:e5:19 |
+-------------------------------------------------+-----------------------+----------------+-------------------+-------------------+

previewでは部分的なタスクしか実行されません (ここではtask5.pcapngがぬけている)
- runコマンドで出力される, “次の状態のコンフィグ”も出力されません
ただし上記のように良い感じに表っぽい出力がなされます

実際にrunコマンドで走らせると以下の様になります

enukane@glenda-lairなう（´・ω・｀）つ ~/Sources/embulk-test % java -jar embulk.jar run config.yml -o config.yml
2015-01-29 11:29:44,264 [INFO]: main:org.embulk.exec.LocalExecutor: Running 3 tasks using 8 local threads
2015-01-29 11:29:44,265 [INFO]: main:org.embulk.exec.LocalExecutor: {done:  0 / 3, running: 0}
/Users/enukane/Desktop/emtestpcap//test5.pcapng,1413615217,45,28:cf:e9:4d:bb:91,c4:7d:4f:56:e5:1d
/Users/enukane/Desktop/emtestpcap//test5.pcapng,1413615217,39,,28:cf:e9:4d:bb:91
/Users/enukane/Desktop/emtestpcap//test5.pcapng,1413615217,155,28:cf:e9:4d:bb:91,c4:7d:4f:56:e5:1d
(中略)
/Users/enukane/Desktop/emtestpcap//test1.pcapng,1413615217,283,c4:7d:4f:56:e5:18,ff:ff:ff:ff:ff:ff
/Users/enukane/Desktop/emtestpcap//test1.pcapng,1413615217,146,c4:7d:4f:56:e5:19,20:c9:d0:d8:37:31
/Users/enukane/Desktop/emtestpcap//test1.pcapng,1413615217,57,20:c9:d0:d8:37:31,c4:7d:4f:56:e5:19
/Users/enukane/Desktop/emtestpcap//test2.pcapng,1413615217,45,c4:7d:4f:56:e5:19,20:c9:d0:d8:37:31
/Users/enukane/Desktop/emtestpcap//test2.pcapng,1413615217,39,,c4:7d:4f:56:e5:19
(中略)
2015-01-29 11:29:47,517 [INFO]: main:org.embulk.exec.LocalExecutor: {done:  3 / 3, running: 0}
2015-01-29 11:29:47,517 [INFO]: main:org.embulk.exec.LocalExecutor: {done:  3 / 3, running: 0}
2015-01-29 11:29:47,517 [INFO]: main:org.embulk.exec.LocalExecutor: {done:  3 / 3, running: 0}
2015-01-29 11:29:47,535 [INFO]: main:org.embulk.command.Runner: next config: {"type":"pcapng_files","paths":["/Users/enukane/Desktop/emtestpcap/","/tmp"],"threads":3,"schema":[{"name":"frame.time_epoch","type":"long"},{"name":"frame.len","type":"long"},{"name":"wlan.ta","
type":"string"},{"name":"wlan.ra","type":"string"}],"done":["/Users/enukane/Desktop/emtestpcap//test1.pcapng","/Users/enukane/Desktop/emtestpcap//test2.pcapng","/Users/enukane/Desktop/emtestpcap//test5.pcapng"]}

-oオプションで実行中のコンフィグと同じパスを指定してやると, 元のコンフィグに「今処理したファイルリスト」を付け加えます
- 既にdoneが合った場合とか考慮してない等々で今はきちんと動いてない模様… (to be fixed)
- いわゆるcommit reportとして, 次回に重複処理しないように考慮 (したかった)
outがstdoutになっているので, previewの様な表ではなくcsv形式で出力.

embulk弄ってたときのメモ

embulkのREADMEをよめばだいたいどうにかなる。
bundleコマンドで作成したディレクトリ以下でプラグインの新規追加・名前変更等したときは, 再度bundleコマンド発行すること
本来的にはinputプラグインではなくFile input内のparser/decoderプラグインとして造るべきでは？
- 処理対象のファイル一覧→スレッドへの分配あたりを再開発してる感
- input/output以外のプラグインがどの程度rubyで差し込みできるのかよく見えない. 要調査.
  - file inputのメインのロジックはJava側で書かれてるようなのでbundle側からのインタラクション次第か?
task to threadsのベストプラクティスが欲しい…
transactionとrunの間のデータ受け渡し, これでいいのかな感
- 引数でスレッドローカルなオブジェクト渡すものだと思ってたけど…

life, memo

Comments

2015-01-25 Softbank から IIJmio にかえた

前回の検討の続き。結局乗り換えた。ファミリーシェアプラン(7GB)で, 音声SIM 1枚(MicroSIM)とデータ専用SIM 1枚(NanoSIM).

sim

転出・転入の手続き周りでかかった費用は以下の通り.

MNP転出側 (Softbank)
- 解約手数料: 0円
  - 2年1ヶ月目ちょうどだったので
- MNP転出手数料: 3000円
MNP転入側 (IIJmio)
- 初期費用: 0円
  - 後述するASUSのキャンペーン
その他:
- 端末購入費用: 28940円
  - ASUS ZenFone 5 A500KL-RD16
  - IIJmio音声通話パックと同時購入でパッケージ費用 3000円がタダになるキャンペーンやってた

月額費用はこんな感じになるはず (予定)

合計: 3520円 (税込)
- 月額費用: 2560円
  - ファミリーシェアプラン 7GB
- 音声通話機能付帯料: 700円

“@t.vodafone.ne.jp”なメアドが消滅したので, 何人かとのリンクが消滅したことになる. 数年来連絡とってないひとばっかりなので問題にはならないでしょう, きっと.

life, mobile

Comments

SIM Freeか否か

今月がちょうど Softbank の2年縛りが切れる月なのでそろそろどうするか考えてみる. “@vodafone.ne.jp”なアドレスに執着が無ければ移るかも.

直近4ヶ月の Softbank 請求金額

月	1月(計算中)	12月	11月	10月
合計	8232	9214	9344	8847
基本使用料	934	934	934	934
パケット定額料等	5200	5200	5200	5200
通話料	400	340	460	0
オプションサービス料	1685	1250	1250	1250
その他	13	13	13	13
端末台(月月割引き後)	0	1018	1018	1018
消費税	-	459	469	432
通信料	-	2.55GB	5.08GB	3.23GB

オプションサービス料はこんな感じらしい。削ったつもりだったけど、まだいろいろついてんね。

月	2月	1月	10〜12月
合計	1750	1685	1250
S!ベーシックパック(i)	300	300	300
Wi-FIスポット(割引後)	0	0	0
あんしん保証パック(i)	475	475	475
テザリングオプション(割引後)	500	435	0
iphone基本パック	475	475	475

少なくとも以下のオプションは削れそう。950円のマイナス。

iPhone基本パック (475)
あんしん保証パック (475)

削ったとして結局のところ1月換算で行くなら, 8232 - 950 + 460 (消費税概算) = 7700ぐらい。なお、MNP転出手数料は2000円。

みおふぉんに変えてみるプラン

とりあえず端末代は度外視するとして。

ファミリーシェアプラン 7GB : 2560円/月 (税抜)
SIMカード(一枚目): 音声通話機能付き 700円 (税抜)
SIMカード(二枚目): データ専用 0円(税抜き)

初期費用、通話料、ユニバーサルサービス料は含まれてない。音声通話は20円/o.5分(税抜き)とのこと。

初期費用: 3000
- ここに転出手数料 2000
通話料: ソフトバンク側と同じく400円程度とする
ユニバーサルサービス料: 誤差なので含めない

これで合計金額を取ると, 月4000円ぐらい？