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

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

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

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

諸々の前提

• とりあえず無線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

• 参考

  • BB60C
  • USB-SA124B
  • BBC60 Demo and Remote
  • SA-Series Videos

• 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
  • お値段
    • とはいえこの性能比で考えれば破格. 単純に予算の問題

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

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

• embulk-input-pcapng-files
• enukane/embulk-input-pcapng-files

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) にデータをはき出してくれます.

追記

• 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インターネットに出て行けてることが確認できたら完了.

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

速度計測

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

• なお上流はフレッツ光マンションタイプ・ミニ(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側経由の速度は省略

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

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

速度計測その3

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

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

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

• https://github.com/enukane/embulk-plugin-input-pcapng-files/pull/1
• https://github.com/enukane/embulk-plugin-input-pcapng-files/pull/2

はじめに

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

• enukane/embulk-plugin-input-pcapng-files

• rubygems - embulk-plugin-input-pcapng-files

• ※

  • http://www.slideshare.net/enukane/comiket-space-29723016
  • http://www.slideshare.net/enukane/comiket-space-c86
  • http://www.slideshare.net/enukane/c87-wifi-comiket-space

中身はまんま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の間のデータ受け渡し, これでいいのかな感
  • 引数でスレッドローカルなオブジェクト渡すものだと思ってたけど…

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

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

• 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”なメアドが消滅したので, 何人かとのリンクが消滅したことになる. 数年来連絡とってないひとばっかりなので問題にはならないでしょう, きっと.

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

直近4ヶ月の Softbank 請求金額

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

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

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

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

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

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

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

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

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

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

2014年のまとめ

• 犬吠埼に初日の出観に行った。寒かった。
• C85のデータをまとめて公開した: “続・ららら、(無線的に)素敵なComiket Space”
• 部署名が一昨年のそれに戻った
• 某文学系イベントでの無線LANネットワーク構築の準備・面倒見その他をした
• 会社が神保町から飯田橋に引っ越した
• ロードバイクかった。2013年に比べるとあんまり乗ってない。
• 秋山郷ハッカソン行ってきた。成果はない。星空綺麗だった。
• 夏のコミケで“キャプチャリング802.11”を出した
• C86のデータをまとめて公開した: 続々・ららら、(無線的に)素敵なComiket Space C86
• 某ゲーム系イベントで一部無線LAN周りの面倒見をした
• 亀有から王子に引っ越した。githubで管理しようと思ってたけどうまくできなかった ( 残骸 )
• 冬コミ落ちて、引越を言い訳に何もしなかった (最終日だけデバイス動かした)
• リバウンドしてた (一昨年の体重に戻った)

2015年にやりたいこと

• 夏コミ(C88)に受かりますように
• C87で取ったデータの分析 & まとめ。手法の再検討とC88でのリトライをしたい。
• “Linuxのブートプロセスをみる”のPlan 9版を書いてコミケで出したい
• 9load の EFI対応? とりあえず勉強するところから…
• OSvでNetVM的なことできないか遊んでみる
• DPDKで遊びたい
• オレオレネットワークツールをきちんとまとめよう
• 集めたデータ分析の方向の掘り下げ方を考えよう
• 通信速度その他を図りながらの計測デバイスを作ってみる
• Raspberry Piで玄関先カメラシステム作りたい
• ネットワーク自動化周りをきちんと自宅に組み込む, 生活で使う
• 自宅鯖環境の復旧
• 監視系の作り込みをしよう
• こんどこそちゃんと背景透過なグレンダさんステッカーを作る
• 忍耐を要求しないHTML/JavaScriptというよりWebUIの書き方・常道を勉強する
• 論文読んだらきちんとまとめと所感を書く習慣をつけよう
• 手元でてきとーに作ったツールをきちんと見直してどこかに放り込んでおく習慣をつけよう
• 2016年の初日の出は犬吠埼か九十九里のどこかで観たい
• 電子書籍になれよう
• やせよう ( -15kg )
• もっと馬鹿をやろう. Keep it stupid, simple (誤字にあらず)

本記事は、システム系論文紹介 Advent Calendar 2014 12/11 のための記事です

はじめに

本エントリでは、NSDI’14 にて発表のあった “NetVM” について紹介します。

“NetVM: High Performance and Flexible Networking Using Virtualization on Commodity Platforms”

論文の概要

• タイトル: “NetVM: High Performance and Flexible Networking Using Virtualization on Commodity Platforms”
• 著者: Jinho Hwang et al.
• 出典: 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI’14)

この論文では表題にも登場する”Commodity Platforms”いわゆる普通の(?) x86マシンを使った、高度かつ高速なネットワークサービスを実現するための基盤として、”NetVM” というプラットフォームを提案&実装しています。これまでお高い専用のハードウェアでなければ実用に足る性能が出せなかったファイヤーウォールやルーティング、ロードバランサといったネットワークに必要な諸機能。これらをソフトウェアだけで実現し、いわゆるNFV 的なものの基盤として使える様にするといったことを目的としています。特にこの論文では、ハードウェアアプライアンスに負けない性能(==ワイヤーレート)を目指しつつ、ソフトウェアとしての展開の容易さや機能実現に対する柔軟性といったネットワークサービスインフラにおける利便性を実現することを主眼としています。

ここがひと味違うよNetVM

ここではNetVMを支える技術、として論文中よりNetVMにおける「こだわり」ポイントをいくつか紹介します。

Virtualization: 仮想化前提だよ

NetVMにおける仮想マシン: 1コンポーネント == 1VM

NetVMにおける一つの特徴として、仮想化環境によるネットワークサービスの実現を特に意識している点が上げられます。 いわゆるハコモノを用いる一般的なネットワークでは用途に応じて様々なハコを組み合わせてネットワークを構成します。 これにはたとえばスイッチやルータ、ファイヤーウォールなどといったコンポーネントに設定を投入し、間を LANケーブルで敷設するイメージでしょうか。 ブロードバンドルータなど一つのハコにまとめている場合もありますが、より大規模かつ高速な処理を要求される場合は 専用のアプライアンスを持ってくることが一般的でしょう。

NetVMでは、これらの物理的なハコとしての形を取っ払ってKVM上の仮想マシンを新たな仮想的なハコとしてそこに機能を押し込めています。 これによりソフトウェアの柔軟性(デプロイや変更の自動化、大規模化 etc)といった利点をネットワークの構成に導入しています。

それぞれのVMはハコモノとして、これまで行ってきたのと同じようにパケットの入力とそれに基づく出力の決定(宛先の変更やパケットの書き換えなど)を行います。 もちろん仮想マシンに押し込めたところで物理配線が消える訳ではないのでそれらは依然として存在しますが、このハコモノの間を埋めるLANケーブル (とスイッチング)の役割の一部をNetVMではハイパバイザでも提供します。NetVMではこのホストで動く部分をNetVM Core, NetVM Managerと呼称しています。 ネットワークコンポーネント間の結線にあたるこの部分もソフトウェアとして抱き込むことで、ハコモノを仮想化したのと同様の利点をネットワーキングにも導入しています。

VMという区分によるセキュリティ

一つのハコモノを一つのVMに押し込めて動かすことはセキュリティ面でも利点があります。 NFV的な、一つの物理ハードウェア上に複数のネットワーク、複数のお客さん環境が載っている場合は それぞれの間がまぜこぜにならないことが肝要です。 KVMが既にVMという区分で提供しているアイソレーションの仕組みに乗っかることでNetVMでは 各ネットワークコンポーネントのセキュリティを担保しています。

加えて必要なのは、それぞれのネットワーク間を間違って繋がないことです。 ここはホストOSつまりNetVM CoreやNetVM Managerの領分になりますが、このためにVMのグルーピングができるようになっています。 これにより、あるVM群は特定のユーザのもの、また別のVM群はそっちのユーザのものといった形で内部的に分離する事が可能です。

なおあくまで内部的な区分けにつき、外に出たフレームは対象とはなりません。このため実際にNFVっぽいことの基盤として使うにはその部分でVLANかますなりトンネリングするなりでネットワーク的に区分けすることが必要だったり？また、一つの物理的なハードウェア上での組み合わせを主眼にしているためか外に出ないといけないような場合の想定があまりなされていない感じもあります。

High Performance: パケット処理性能↑

ハードウェアなアプライアンス箱に性能で勝つ、というのを第一目標においているためかチューニングやテクニックの記述に論文のそこそこの部分を割いているためその一部をここでは解説します。

DPDKで User-land Packet Processing

いわゆる「ポーリングモード」+ 「ユーザランドにおけるパケット処理」+「バッチ処理」による高速化は、Intel DPDKのリリースやnetmap、あとちょっとマニアックなところだとrump(はどうなんだろう…?)などの登場によりもはや当たり前のテクニックとなってきました。特に”なんらかのアプリケーション”に特化した通信を行いたい場合は、これまで先人がせっせと築き上げてきたOSのレイヤやらコンテキストスイッチングによるオーバヘッドをぶち抜けるため非常に高速にパケットを処理することが可能です。

これらの仕組みはDPDKでもnetmapでも、基本的には直接ハードウェア(NIC)を触ってる人のみへの恩恵です。一方、NetVMではベースにDPDKを用いることでこれらの技術を利用しつつ、ネットワークサービスのコンポーネントたるVMの中のアプリケーションに対しても同様の利点を提供しています。

システム全体でのパケットバッファ共有

DPDKやnetmapは基本的に、NICとネットワークアプリケーションとで送受信リングとパケットバッファを共有することでコピーコストの削減を行っています。 NetVMでもDPDKを利用しているため、ホストOSとNICとの間でこれはすでになされていますがこの構造をさらに拡張し、VMにたいしても 同様の処理ができるように巨大な共有メモリ領域を用意し、ダミーのvirtual PCIデバイス経由でVMに対してこれを晒しています。 これによりNIC-ホストOS-VMの三者間でのZero Copyを実現しています。 このZero CopyはVM-VM間でも有効であり、ホストOS(NetVM Core)を通してのコンポーネント間のパケットのやりとりにあたっても 同様の恩恵を得ることができます。これは、ホスト-VM間のRx/Txリングがそれぞれ独立である一方で”同じネットワーク”間では パケットバッファが共有されているためです。なお先に述べたネットワーク間のアイソレーション機能(グルーピング)は このパケットバッファの共有範囲を分けることでも実現されています。

CPU特性の活用

バッファ共有によるZero Copyの拡張に加えて、マルチコアシステムを前提として以下の工夫がなされています。

• Lockless なシステムデザイン
• NUMA-awareなデザイン

netmapでも同様だったかと思いますが(マルチコアの場合はどうだったっけ…)、共有のパケットバッファの操作にあたりNetVMではロックを用いません。 あるキュー(Rx/Tx)は同時にホスト内またはゲストから操作しないように構成されます(できないのではなくやらない)。 ある一つのキューに対してロックが必要なケースは以下の場合です。

1. ホストOS側でそれぞれのコアが同じキューを触ることがある場合
2. ゲストOSとホストOSが同じキューを触ることがある場合

これらを避けるために、NetVMではコア間で触るキューを分けるようになっています。 まずNetVMのホストOS側ではコアごとにNICおよびVMとのキューを分けるようになっています。 これにより1の、同じキューを別々のコア(上で動作するスレッド)が触ることがないようにしています。 次に、ゲストOS(VM)側のスレッドとホストOS側のスレッドが同じキューを操作するシチュエーション(2)ですが、 これも1と同様にあるゲストOS(VM)上のスレッドが動くCPUを限定することで対処しています。 このゲスト上のスレッドも、同様に自分のCPUに割り当てられたキューしか触れないようにすることで実質的に いわゆるキューを挟んだconsumer-producerにおいてRX側では「ホストOSのスレッドとしてキューにpush」と 「VM上のスレッドとしてキューからpop」が一つのCPUで完結することになります(これらは1つのCPU上では同時に実行されないためロックもいらない)。 このあたりの実装にはKVMのvCPU周りの管理機構をいじくって実現したとのこと。

NetVMではNUMAなマルチコアシステムにおけるメモリの距離とキャッシュの扱いについても考慮が入っています。 基本的なデザインとして、NetVMでは自分のコアに距離的に近いメモリ領域以外は触らないように構成されています (遠いメモリにアクセスするとキャッシュは汚れるは遠いわで良くないよというお話はここでは割愛)。 これは上記の「キューごとのコア」という構造をベースに作られます。 まずNetVMではそれぞれのコアごとに触るメモリ領域を分けます (総メモリ量/コア数 == 1つのコアが触るメモリ領域)。 そしてその各々のメモリ領域に「キューごとのコア」が作られ、ゲスト(VM)と共有されます。 先に述べたように、Locklessデザインの制約によりあるキューはそれぞれ対応するCPUからしかアクセスされないため、 あるCPU(とその上で動くホスト/ゲスト上のスレッド)は常に自分から近いメモリ領域のみを触る様になります。 これは全てのホスト-ゲスト間のみならず、ゲスト-ゲスト間でのパケットのやりとりでも有効であり、最終的に NICにパケットを引き渡すまでlocalityを維持したまま通信ができるようになります。

終わりに

ここではNSDI’14より”NetVM”の紹介をしました。こういったNFV的なプラットフォームはネットワークベンダやキャリアなど各社それぞれ様々な構想を出しており、それらの一例として作り方まで踏み込んだものとして面白い論文ですが、なによりもチューニングに結構命かけているあたりがこのNetVMの面白いところです。

今回ボツになった他の候補者達

最後に、今回読もうと思ってた論文の候補たちを並べておきます。

1. Unikernels: Library Operating Systems for the Cloud (ATC’13)
2. HACK: Hierarchical ACKs for Efficient Wireless Medium Utilization (ATC’14)
3. Hyper-Switch: A Scalable Software Virtual Switching Architecture (ATC’13)
4. Rekindling Network Protocol Innovation with User-Level Stacks (SIGCOMM Computer Communication Review)

Unikernelsは@suma90h さんが既にシステム系論文輪読会でお読みになってた のでパス。HACKは、無線LAN系 & 今年のATCでのBest Paperということもあって気になっているのですが別枠で読むことに。3や4は、NetVMと同じく”えすでーえぬ”とか”えぬえふぶい”といった類いに属しそうなのと、先日のIIJ-II セミナーで”ClickOS and the Art of Network Function Virtualization”のお話があったので関連文献として上げてみました。