特に必須ではないらしいけど、ワイヤーアンテナにはバランを噛ましましょうという記述 があったので試しに作ってみた。 無線機側の同軸ケーブルは外部導体が GND に落ちてい る「不平衡」である一方、アンテナからの入力は 内部・外部導体ともに電気的に対称で 「平衡」なのでこれが必要なのだとか。

  1. バランから作るお手軽HFワイヤ・アンテナの製作
  2. 簡単に作れる、バランの作り方
  3. パッチンコア(クランプコア)でバランを自作する
  4. バランの製作
  5. 長波対応ロングワイヤ用バランの製作
  6. バランの製作

基本的な作り方は1番目のエントリを丸々なぞった。FT-50-43なるトロイダルコアを使う のが筋らしい。が見つからなかったので秋月のそれっぽいやつで代用した。5番目のエン トリを見ると巻き数にきちんと計算が必要らしいのでてきとう極まりない。

巻いたトロイダルコアはこんな感じ。 なおどこのサイトの記述か忘れたが、撚り線を作 るには電動ドライバに束ねた線の端を噛ませて作ると良いらしいとのこと。 もう一方の 端を手かペンチで保持してゆっくりドライバを回すといい感じに撚れる。

束縛されるトロイダルコア

完成したバランはこんな感じ。赤黒のターミナルがアンテナ行き、SMAが無線機行き。

バラン試作0号

SWR計を持ってないんでどれほどきちんと作れてるのかは不明。

ところで手持ちの受信機で HF 帯まで受信できるの ALINCO の DJ-X7 しかない。早くア ップコンバータが欲しい。

HackRF の遊び方を広げるための一手段として電波望遠鏡の実装に使えないかを考えてみる.

参考

構成

2015-09-08-diy-rt

  • SDRデバイスはRaspiで操作
  • simple_raを利用して観測・記録
    • 場合によっては改造すること
    • 要ソース読み

必要な物品

既に持っているもの

部材 品目 値段 個数 用途 備考
SDRデバイス DVB-T+DAB+FM USB チューナ 1,420 1 SDR用 BNC端子へのアダプタ必要, できればこっちを使う
HackRF One $300.00 1 SDR用
BNC-SMA コネクタ ??? ??? 1 DVB-T用
同軸ケーブル(SMA) ??? ??? 2 SDRデバイスへの接続用

買うべき物

部材 品目(候補) 値段 個数 用途 備考
BS/CSアンテナ 東芝 BCA-453A 4,580 1 受信用 周波数範囲(11.7〜12.75GHz), ビックカメラの方が安いかも
アンテナ取り付け金具 DXアンテナ VM321H 3,730 (送料込み) 1 ベランダ取り付け用 9cm幅, 7cm下がる様な金具
BS/CS ブースタ 日本アンテナ CSB-C25-SP 2,370 1 アンプ用 電源供給が必要, 場合に依っては電源付きのブースタの方がいいかも
パワーインサータ プレクス PX-LNBADAPTOR 1,980 1 アンテナへの電源供給(ラインブースタの場合) 分配器が必要
分配器 HORIC BCUV-971 880 1 パワーインサータと入出力の結合 40cmのケーブル x 2が付属
すき間ケーブル(F形) SOLIDCABLE #3232E/0.3 1080 1 窓通す用 30cm
同軸ケーブル(F形) S-4C-FB 570 2 外用 + 中用 1.5m
F-SMA変換アダプタ F-SMAP 変換アダプタ 563 1 SMA同軸ケーブルへの接続用 SMAJ-SMAJが必要

合計 17000円弱?

概要

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

計測対象

今回、計測対象にしたのは以下の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 コマンドの以下のオプションを用いました。

1
% iw wlan0 survey dump

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

1
2
3
4
5
6
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

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

1
2
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 のチャネル遷移部分で取得するようにしました。

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

1
[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

概要

リンク: 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.

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

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

感想

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

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

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

聞いてたセッション

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

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

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

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

パケット集め

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

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

終わりに

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

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

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

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

やりたいことベースでのおおよその要件は以下の通り (貧乏人にしては盛りすぎだ!生意気だ!等のコメントは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])2
    • 掃引時間はRBWの二乗に反比例
    • 掃引時間は周波数スパンに比例

候補

GigaSt v5c

  • 参考

  • Pros

    • 安い! (送料込みで3万円以下)
    • USBバスパワー駆動
    • 内部的にはシリアル(VCP) & コントロール等々のドキュメントはそろってるので他OSでも触るのは簡単そう
  • Cons
    • ケースはないので自分で用意
    • 「グラフデータ保存機能」でどんな形式がサポートされてるか
    • 注文ウィンドウがよく分からない (受付してない時期がある?)

RF Explorer 6G Combo / WiFi Combo

  • 参考

  • Pros

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

Aaronia SPECTRAN HF-6060V4 / HF-6060V4 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

「無線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

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

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

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

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

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

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

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
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

追記

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

はじめに

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

設定

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

動作確認

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にすると少し良くなるようだ.

追記 (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はできないので手打ちで全部書く必要があります.

1
2
3
4
5
6
7
8
9
10
11
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コマンドで指定してみるとこんな感じ

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
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コマンドで走らせると以下の様になります

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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の間のデータ受け渡し, これでいいのかな感
    • 引数でスレッドローカルなオブジェクト渡すものだと思ってたけど…