fluent-plugin-sflow

JuniperやAlaxala, NEC製品などでサポートされているsFlowプロトコルのサンプルを受信するFluentdプラグインを書きました。

netflowプロトコルについては repeatedly さんが既にfluent-plugin-netflowを公開されています。 今回NECのIXシリーズからフローデータを送りつけたいという要望が某所であったため、実装してみました。 とはいえsflowのプロトコルを捌く部分は別の方のパーサに頼っています。

使い方

fluent-gemやtd-agent-gemでインストールするだけです。

1
% fluent-gem install fluent-plugin-sflow

設定項目は以下の通りです。 待ち受けアドレス(bind)、待ち受けポート(port)そしてタグ名ぐらいしかありません。

1
2
3
4
5
6
7
8
9
10
11
<source>
  @type sflow
  tag sflow.example

  bind 0.0.0.0
  port 6343
</source>

<match sflow.example>
  @type stdout
</match>

host-sflow と組み合わせたテスト

実際のテストにはスイッチやルータが必要ですが、手元で簡単に試すために host-sflow を導入します。 ここではMac OS X (MacBookPro)上に導入しWi-Fiのインタフェース(en0)のデータをサンプリング、先に挙げた設定で同一ホスト上で動作するfluentdに投げ込んでみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
% git clone https://github.com/sflow/host-sflow.git
% cd host-sflow

% make

# pcap のターゲットデバイスとして en0 を指定する
% cat > /tmp/test.conf
sflow {
  polling=10
  collector { ip = 127.0.0.1 udpport=6343 }
  pcap { dev=en0 }
}
^D

# host-sflowの起動(デバッグ目的で -dddd としている)
% sudo ./src/Darwin/hsflowd -dddd -f /tmp/test.conf

fluentdの標準出力をしばらく眺めていると、以下の様にフローサンプルが出力されます。この時は *.twttr.com (twitter) への通信がキャッチされたようです。

1
2
3
4
5
6
7
% fluentd -vv -c example/fluentd.conf
(中略)
2017-03-24 18:52:50.054347000 +0900 example.sflow: {"agent_address":null,"i_octets":0,"o_octets":0,"interface":6,"input_packets_error":0,"output_packets_error":0}
2017-03-24 18:52:52.519715000 +0900 example.sflow: {"agent_address":null,"sampling_rate":"400","i_iface_value":0,"o_iface_value":0,"ipv4_src":"199.59.148.241","ipv4_dst":"192.168.10.17","udp_src_port":1900,"udp_dst_port":57347,"frame_length":1486,"frame_length_multiplied":594400,"tcp_src_port":443,"tcp_dst_port":58076}
2017-03-24 18:53:01.984184000 +0900 example.sflow: {"agent_address":null}
2017-03-24 18:53:09.934539000 +0900 example.sflow: {"agent_address":null,"i_octets":0,"o_octets":0,"interface":6,"input_packets_error":0,"output_packets_error":0}
(中略)

ネットワーク機器にてよく見られるカウンタサンプルとフローサンプル以外にも、host-sflowはOSやアプリケーションの各種メトリックを集めsFlowプロトコルに載せて送信します。 現状の fluent-plugin-sflow ではカウンタ/フローサンプルのパースしかサポートしていないため、それらのメトリックは空扱いになります(上記5行目)。

ToDo

  • bindata 1.8.1以上への対応
    • 現状 Sflow5rawpacketdataVLAN の type メンバが BinData::Record あたりで定義されてる名前と被ってるらしく怒られるので、1.8.1にしている
    • fluent-plugin-netflowは2.5.3ベースであり、こちらと揃えたい
    • 名前の変更にはおそらく次の項目をクリアする必要がある
  • パーサーの取り込み
    • 現状、NETWAYS/sflowのパーサをリポジトリごと丸っと使っている
    • ライセンスとオリジナルを明記した上でパーサとモデルの部分だけコピーしてくる
    • または全部1から書き直す
  • IPv6対応

2017/03/19 でレベル30になった。不毛の20代が終わり、そして不毛の30代が始まった。 節目でもあるのでざっくりとここ10年を振り返って思い出せることをつらつらと書いてみる。

  • 2007
    • 大学生3年生
    • サークルに入らず毎日自宅と大学とを行き来する量子的な大学生生活。大学に知り合い?知らない子ですね。
    • 週3で入れてたリサイクルショップのバイトでのみわずかに人間的なコミュニケーションを行う
    • 一年前に出来たつくばエクスプレスがなければしんでいた
    • 念願のEl Camino de Santiago 巡礼で2週間歩き通す旅にでた。300km超。帰ってきても体重は変わらなかった。自分探しの無意味さを知る。
  • 2008
    • 大学生4年生
    • OS系を志望して、やわらか研究室に配属される。
    • OSやりたくて入ったけど分散システム系のネタをやることになる
    • 今もつきあいのある頭のおかしい人たちを知る(syonboriさん, ozaさん, hirakuさん, yoshinabuさん, goさん e.t.c)
    • はじめてのコミケ一般参加@冬(go先生のガイド、しかも始発組だった気がする…)
  • Before Twitter と Anno Twitter の境目
  • 2009
    • 大学4年、卒業。良く分からないけど卒業に際して学類長賞もらう。一言とはいえ友達も知り合いも0なのに前で所感をしゃべるの拷問。
    • モラトリアム延長のため大学院に入院する。研究室に住むという道を選ぶ。
    • 後輩にさらに頭のおかしいのが入ってきて一般人層として肩身が狭くなる (えむばさん、frsyukiさん、athlonzさん, kdmnさん e.t.c)
    • 7月、syonboriさんその他に触発されてtwitterに手を染める(初Tweet)
    • お外に出ていた先輩・後輩経由で外の頭のおかしい人たちを知る。世の中は広大だわ。
    • はじめてのコミケサークル参加おてつだい@yoshinabuさん & goさん’sスペースでサークル参加の楽しさを知る
    • 沼津の方にインターンに行く。Linux系の怖い人たちを知る。
    • はじめてのハッカソン
    • Plan 9への傾倒、グレンダのぬいぐるみ製造の外注に着手する
  • 2010
    • はじめての勉強会発表。いろいろとひどかった(主催者の方ごめんなさい)けど、いろいろ学びをえた。
    • グレンダぬいぐるみが降臨、信仰が始まる
    • 修士2年生、研究室の机の下の住居環境の充実化が一層進む。研究は進まない。
    • グレンダのオリジナル作者さんからグレンダぬいぐるみについて問い合わせが来る
    • 就活、なんとか滑り込む。
    • はじめてのコミケサークル参加、修論ほっぽって原稿書く。直前まで仕上がらず大量のカフェインドーピングの結果、カフェ中の恐ろしさをカラダで学ぶ。
  • 2011
    • 震災当日、風邪を言い訳にゼミサボって寝てたら頭上から大量のガジェットが降り注ぐ。
    • 震災を言い訳に研究の引き継ぎをろくにやらずに逃亡そして修了。研究成果のOSS化ェ….
    • 某社で社畜はじめた。スーツ生活つらい。同期の面白い連中を知る(akiray03先生, hizumiさん, suu_gさん, smison先生 e.t.c)
    • 配属告知の当日に夢で、まったく希望してない部署を告げられ13Fの窓から飛び降りるところで目が覚める。
    • 分散システムっぽい研究の反動で、OSとかネットワークスタック開発っぽいことやるお仕事をすることになった。
    • おちんぎんでお寿司を食べる快楽に目覚める
  • 2012
    • 社畜2年目
    • 身近に識者がいない無線LANのお仕事が降ってきて、無線沼に嵌まり始める。
    • 新製品開発でふぃーばーしはじめる
    • そのせいで気が狂ったのか、生ハムの原木を買ってしまう。もう二度と買わない。
    • お仕事で温泉ハッカソンに行く
  • 2013
    • 新製品リリース判定前日、お仕事で初めて徹夜仕事をキメる。作業中意識を失ってお花畑でスキップする白昼夢を見、アハハハハと笑ってるところで目が覚め我に帰る。
    • 結局解決せず、自分の担当分のトラブルでリリース延期をやらかしかけるも、帰って寝てる間に妖精さん(先輩)が問題箇所見つけてくれたおかげでGOサインがでる。
    • 学生の卒業旅行に混じって奥日光に行く
    • 社畜3年目、研究室の先輩と同期が後輩になる
    • 某BSD系のハッカソンに参加@トロントするも特に成果がないままおめおめ帰ってくる
    • 反省してヒゲを伸ばし始める
  • 2014
    • 社畜4年目、飯田橋へのマイグレーション
    • 先輩の導きで「イベント無線LAN構築・運用」というアートと快楽を教え込まれる。が、その先輩はすぐに旅立ってしまった。
    • 無線LANパケットキャプチャ沼に嵌まる
    • 2回のイベント無線LAN(2014年内)
  • 2015
    • 社怪人5年目、職場に新しい無線LANフレンズができる
    • CONBUにプロジェクトメンバとして初参加する@YAPC::Asia 2015
    • 唆されてハムやら陸特やらの勉強を始める
    • CONBUコアメンバにhiringされる。テレカンでもF2Fでも沈黙を貫く仕事をしないコアメンバになる。
    • 葉巻と西洋剃刀にハマる
    • 先輩後輩知り合い同期が大量に旅立ってなんとなく焦り始める。でも焦っても特に何もないことに気づいて落ち着きを取り戻す。
    • 8回のイベント無線LAN構築・運用(2015年内)
  • 2016
    • 初めての3週間連続勤務、残業3桁
    • 社壊人6年目、新製品開発で燃え尽き気味になり以降やりたいことをやりたいようにやりはじめる。
    • はじめてのJANOGと沖縄、まさかの懇親会申し込みておくれ
    • 夏C90で、はじめての印刷所利用(オンデマンド印刷)
    • 先輩後輩知り合いが大量に結婚しはじめてなんとなく焦り始める。でも焦っても特に(同上)。
    • 冬C91で、コミケサークル参加たぶん10回目、10冊目の薄い本
    • 20代最後の年が漫然と流れゆく。「而立〜さよなら20代〜」のそれぞれの曲がさらに心に突き刺さる。
    • 8回のイベント無線LAN(2016年内)
  • 2017
    • 自分が何のエンジニアなのか悩み始める。でも悩んでも特に(同上)。
    • 3/19 ああ、もう戻れない

三十路初心者を慰めてやろうという心ある方々の援助を募集しております> ほしいものリスト

まだ20代の人はこれを聴くといいよ> 而立〜さよなら20代〜

だんだんと自分にしか意味のない指標&グラフが増えすぎてて大変に読みづらいものになったけど、 いつものやつ書きました。「C91 Wi-Fi 〜ららら、(無線的に)素敵なComiket Space〜」。

今回は、また自スペースが西1に戻ってきました。 そのため前回のC90 (西3だった)とはまた様子が異なっています。 比較のために、次はできれば東に割り当てられたいですね。

今回は新要素として以下を追加しています。

  • “18.1 AP滞在時間のヒストグラム(10分以上のみ抽出)”
    • APが見えていた時間をプロット
    • 大半がヒットアンドランで0秒付近に張り付く傾向があるので、一定時間以上に絞って長期傾向を見る
  • “19.1 端末の滞在時間ヒストグラム(10分以上のみ抽出)”
    • 同上
  • “20. Data & BlockAckフレームの収集数/s”
    • “14. 正常フレームの収集数/s” のうち、さらに Dataフレームと Block Ackフレームに絞り込み
    • サンプリングが妥当であれば、このFPSがデータ送信の活発さの指標になりうる
    • ただし長さは考慮されない
    • ただし高レートすぎて見えないフレームは Block Ack でしか考慮されない
      • Block Ack またはその他の要素から、これらのフレームを復元する方法が必要
  • “21. FCS OKフレームの時間的占有率”
    • 毎回1秒キャプチャしてた間に見つけたFCS good なフレームの Duration (秒) と 1秒内の割合の推移をプロット
    • 「13. チャネル使用率」のうち、どれくらいが有効に使われていたかを判断できるはず
      • 正確な一致には FCS bad なフレームの考慮による検証が必要 (TODO)
    • チャネル使用率との差分が、無駄になった時間
      • このDurationのうち、データフレームに使えた時間と長さを考慮してチャネル使用率との対比を取ると、有効に使えた度合いが取れる?

FCS badなフレームのDurationがどれくらい正確なのかは今後要検証。 これが正確にとれており、Durationの合計がチャネル使用率と合致するならサンプリング精度が良いという指標になりそう。

また、FCS badなデュレーションと これと、プリアンブルだけの情報が上手く取れると高レートなフレームの流れが

{:TOC}

概要

今冬のコミックマーケット91にて、1日目 西1 み-18a “glenda9” で出展するにあたって 自スペースにハニーポット無線LANアクセスポイント(以下 ハニポAP)を立てました。 ここではその提供方法、構成および結果について記述します。

この手のイベントでは「応仁のLAN」といった面白SSIDを告知する遊びをする人がいます。 これに倣って自分のスペース名をSSIDで告知というのも可能ですが、 せっかくAPを立てるからにはもうすこし遊びを入れたいところです。

もうちょっと真面目な目的としては各種プラットフォームが備えているキャプティブポータル検知の実装を見てみたい、 この手のイベントでいかにもセキュリティの甘そうなAPをおいておくと どれくらいの人が引っかかるのか見てみたいといったモチベーションがありました。

ここではAPとキャプティブポータルを組み合わせてイベント環境にデプロイし、 クライアントの通信を特定コンテンツにねじ曲げて以下の様なページを強制表示するようにしつつ各種ログを収集しました。

ハニーポットAPの見え方

ハニポAPのSSIDとして「 Not Free Wi-Fi」を告知するようにしました。 SSIDの先頭に半角スペースを2つ入れることで、 「0000」で始まるものやアンダースコアから始まるSSIDよりも上位に出現するようにしています。 2.4GHz帯と5GHz帯でSSIDを分けており、 下記の様に2.4GHz帯側には”-g”とのサフィクスをつけました。

このSSIDに接続すると、 大抵のプラットフォームに入っているキャプティブポータル検知の仕組みによりスプラッシュページが表示されます。 Androidのスマホで見ると、ハニーポットAPのSSIDを選択後しばらくすると以下の画面がポップアップします。

ハニーポットAPの機材について

AP本体

ハニーポットAPには、Buffalo WZR-HP-AG300H に OpenWRT を載せたものを用いました。

C90で同様の試みをしたときは Raspberry Pi と USB Wi-Fi アダプタを用いていました(以下)。 その際は、混雑している2.4GHz帯でしか運用せず出力も弱めであったため、 あまり接続数を稼げませんでした。

WZR-HP-AG300H は家庭用APとしてそれなりにきちんとしたアンテナを備え、 2.4GHz/5GHz帯の同時運用も可能です。 OpenWRT を導入できカスタマイズ性も高いため今回はこれを用いてハニーポットAPを実装しました。

APへの電源供給

WZR-HP-AG300Hの消費電力は最大13.2Wであり、付属のACアダプタは定格 12V/2.0A となっています。 通常のUSBモバイルバッテリーではここまでの電圧は出せないため、 簡単にやるにはACが取れる電源などの大きめのバッテリーを用意する必要があります。 これらは価格も高い上にでかいし重いしで大変に邪魔なので、 ここでは以下のページに従ってQuickCharge 2.0対応のバッテリー(今回は AUKEY PB-T4 を利用)から12Vを引き出すようにしました。

なお上記ページのコードでは上手く動かなかったため、 挿入するディレイの長さを変更して運用しています。コードは下記をご参照ください。

後述するとおり 10000mAh のバッテリーで6時間程度は運用できました。 基板に起こすのは間に合わなかったので Arduino そのままとブレッドボードで動かしていました。 たまに結線が外れてリブートしてたり。。。。

簡易キャプティブポータル on OpenWRT

簡易キャプティブポータル実現のため、以下の細工を入れています。

  • 管理用WebUIはWAN側インタフェースでのみ受付
  • LAN から WAN への通信を全て遮断
  • DHCPで配布するDNSサーバを自身(10.0.0.1)に設定
  • DNSサーバにて全てのAレコードのクエリに対して自身のアドレスで応答
  • LAN側(キャプティブポータル提供側)では Apache で HTTP アクセスを待ち受け
    • 全てのHTTPアクセスを /index.html に置き換え

dnsmasqのレコード上書き機能を用いて全てのホスト名に対して自分のアドレスを返すことで、 アクセスを自身にねじ曲げます。 現状 /etc/init.d/dnsmasq にて dnsmasq コマンドの引数に以下を 加えてこれを実現しています。本来的には /etc/config/dhcp に list address の 行を追加すれば動くはずですが、上手く動作しないようでした。

1
--address='/#/10.0.0.1'

キャプティブポータルとして HTTP アクセスを受け付ける側には Apache を用います。 上記 DNS の細工により、HTTP アクセスはこちらに向きますがパスは不定のためリダイレクト等が必要です。 OpenWRT デフォルトの apache では mod_rewrite が使えないため、 AliasMatch でこれを実現します。

1
2
3
4
5
6
7
AliasMatch ^/.+$ /root/www/index.html
<Directory "/root/www">
  Options Indexes FollowSymLinks SymLinksIfOwnerMatch
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

これにより全てのHTTP アクセスに対して /index.html の中見を返すようになります。 このHTMLファイル中に、先に挙げたWebページを詰め込んでおきます。

設置場所

ハニーポットAP は コミックマーケット91 1日目 (2016/12/29) の西ホール1、 み-18a の机の上に設置しました。西ホールのだいたい赤丸の位置に自スペースがあります。

机の上の可能な限り高いところに、 設置しましたができればポスタースタンドなどにくくりつけてより高さを稼ぎたいところではあります。

提供結果

ハニーポットAPの提供は 12/29 09:05:29 から 15:09:15 までの期間、6時間3分46秒に渡って実施しました。

無線LAN

接続しにきたユニーククライアント数は 62 台でした。 この値は、ログ中の接続(Authentication)イベントに紐付くMACアドレスのユニークアドレス数を計上したものです。 なお、いくつかの端末は Authentication Response に対してACKを返せていないため実際にAssociationまで至ったクライアントは 56 台です。

MACアドレスのOUIからベンダ名を引き、分布を図示した物が以下になります。 全体でベンダは10種類でした。コミケという利用環境上、大半がスマートフォンであると推測できます。 この中でも大半が Apple (おそらくiPhone/iPad) と Huawei で占められています。 “IEEE Registration Authority”という名前になっているものがありますが、 一部のスマホでは自社のベンダ名を登録していないためこうなっているようです。

sta-oui-histogram

ハニーポットAPでは2.4/5GHz帯でそれぞれ別のSSIDを告知しています。 以下は帯域毎のユニーク接続クライアント数の分布です。 2.4GHz帯は18端末、5GHz帯は42端末と後者に寄っています。 接続イベント数上も2.4GHz帯は 33回、5GHz帯は 63回となっており、 5GHz帯側に接続しにくることが多かったようです。

sta-per-band

以下は端末の接続持続時間のヒストグラムです。端末が接続してから切断するまでの期間(秒)と発生回数をプロットしています。 10秒単位で丸めています。大半は1分以内ですが、最長で1030秒(17分程度)の場合もあったようです。 300秒にて山がありますが、これは5分毎に走るGTKの更新失敗やらのタイムアウトに起因するものと推測しています。 移動が激しいコミケのような環境では、接続後そのまま明示的に切断せずにクライアントが離脱することが多いため、 このような傾向があるものと考えています。

sta-dur-histogram

DHCP

DHCPサーバがアドレスを割り当てた端末は 50 台でした。 先に述べたとおり、Assocした端末数は56端末であるため6台はDHCPによるアドレス取得まで至らなかったようです。

割り当てたアドレスは10.0.0.0/8から 45 アドレス分でした。 dnsmasqは比較的割り当てアドレスをばらけさせる傾向にありますが、うち5アドレスは重複して配布しています。 デフォルトでは DHCP Lease Time が 1h であるため再利用されたようです。

DHCPクライアントは DHCP Requestのオプションとしてホスト名を付与する場合があります。 このホスト名のユニーク数は今回 39 種でした。 ホスト名文字列として何が付与されるかは端末により異なります。 iOS系だと〜のiPhoneといった形式、 androidだとandroid-XXXXXXXXといった乱数要素を含んだ文字列を用いる場合があります。 詳細は伏せますが、今回は以下の様な文字列が検出されました。

  • iPhone/iPod Touchと推測されるもの(“iphone”, “ipod”が含まれる): 14 個
  • iPadと推測されるもの(“ipad”が含まれる): 5 個
  • androidと推測されるもの
    • “android-XXXXX” の形式: 12 個
    • 機種名: 4 個
  • 不明(端末を推測可能な文字列を含まない): 4 個

上記に挙げたとおり android にてホスト名に機種名を用いている例が4つありました。 以下の通り全てHuawei製品であり、このベンダでは一律このポリシーを採っているのかもしれません。

  • HUAWEI_P9
  • HUAWEI_P9_lite
  • HUAWEI_Mate_9
  • Honor_8

DNS クエリ

ハニポAPで動作しているDNSサーバでは期間中に合計556回 DNS クエリを受け取っており、 この対象レコードの内訳は以下の通りです。

  • Aレコード: 504回
  • AAAAレコード: 50回
  • PTRレコード: 2回

合計 123 個の名前にたいしてクエリを受信しました。 以下はその中で回数の多いほうからトップ10をプロットしたグラフです。 connectivitycheck.gstatic.comcaptive.apple.com のようにキャプティブポータル検知に用いられるホストが多く現れています。 またプッシュ通知を司るホスト向けの通信が多いことも伺えます。

query-top10

AAAA レコードへのクエリのみを抽出すると、以下の5ホストに対してのクエリを受信していました。 IPv6はサポートしていないため、一律NODATAを返しています。

  • connectivitycheck.gstatic.com
  • clients3.google.com
  • mobile.pipe.aria.microsoft.com
  • a.config.skype.com
  • b.config.skype.com

キャプティブポータル

名前でねじ曲げられた先のキャプティブポータルに対するアクセスは以下のようになっています。

  • HTTPアクセス回数: 246 回
  • HTTPアクセスのユニーク送信元アドレス数: 43 個
    • うち5つのアドレスは重複割り当ての可能性あり
  • HTTPアクセス対象ホストのユニーク数: 21 ホスト
    • 先のクエリ対象ホストが123だったのに比べるとだいぶ少なめ
    • HTTPのみ対象のため?

以下はアクセス数の多いほうから、ホスト名のトップ10をプロットしたグラフです。 やはりキャプティブポータル検知用ホストへのアクセスが多めです。

http-host-histogram

アクセス数のヒストグラムをURL全体に拡張し、そのトップ10を並べたものを以下に記載します。 全体では31個のURLに対するアクセスを記録しています。

http-url-histogram

通常のWebアクセスらしきものや、Simejiの通信なども見えますが 大多数はキャプティブポータル検知用のURLに対するアクセスです。

今回検出したアクセス時のUser-Agentは大別すると以下の4種類に分けられそれぞれ一定の役割のもと 用いられているようです。

  • CaptiveNetworkSupport系
  • Dalvik系
  • WebKit系
  • その他

CaptivePortalSupportは主に captive.apple.com 向けの通信に使われていました。 ただしこれだけ、と言うわけではなく以下の様に CaptiveNetworkSupport系とMozilla系のUser-Agentを交互に利用しているようです。

1
2
10.0.0.73 GET /hotspot-detect.html FryingPan.lan captive.apple.com "CaptiveNetworkSupport-325.10.1 wispr" 200
10.0.0.73 GET /hotspot-detect.html FryingPan.lan captive.apple.com "Mozilla/5.0 (iPhone; CPU iPhone OS 9_3_3 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13G34" 200

CaptiveNetworkSupportを含むUser-Agent文字列には以下のパターンが存在していました。 WISPrの仕様上、User-Agent文字列は “WISPR!任意の文字列” ということになっているので CaptiveNetworkSupportの文字列の出典および後続する数値列の意味は不明です。

1
2
3
4
CaptiveNetworkSupport-346 wispr
CaptiveNetworkSupport-325.10.1 wispr
CaptiveNetworkSupport-277.10.5 wispr
CaptiveNetworkSupport-306.20.1 wispr

Android向けであると推測される connectivitycheck.gstatic.com等へのアクセスは主に Dalvik系 User-Agent から なされています。が、Apple系とおなじくMozilla系Uer-Agentでのアクセスも確認されています。

1
2
10.0.0.13 GET /generate_204 FryingPan.lan connectivitycheck.gstatic.com "Dalvik/2.1.0 (Linux; U; Android 7.0; Nexus 6 Build/NBD91P)" 200
10.0.0.13 GET /generate_204 FryingPan.lan connectivitycheck.gstatic.com "Mozilla/5.0 (Linux; Android 7.0; Nexus 6 Build/NBD91P; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/55.0.2883.91 Mobile Safari/537.36" 200

まとめ

  • コミケ91 1日目にてハニーポットAPを動かしてみた
  • 62人のお客さんが釣れた
    • うち43人程度にはキャプティブWebページを見てもらえた模様
    • 前回 (C90, 10人程度) に比べてだいぶアクセスしてもらえた
  • キャプティブポータル検知をしてるらしい動きが見れた
    • iphone & android がメイン?
    • PC系は今回はほぼいないのもあって確認できず
    • 1台だけ Ubuntu マシンがいたが、キャプティブ検知っぽい動作はしていなかった

Future Work

お次やるとしたらこう工夫しようというToDoリスト

  • DHCP リースタイムの延長
    • 1日程度の方が良さそう
  • 運用時の可視化方法
    • 本当は ruby 動かして管理用 WebUI が見れるはずだったけど、上手く動かなかった
  • 自律的な時刻同期
    • 会期中一回落ちて時刻がおかしくなった
    • 3G/LTE で NTP ?
  • 電源モジュールの基板化
    • ブレッドボードはつらい
  • DHCP Fingerprinting で遊びたい
  • 別の場所での運用
    • PC が多そうな環境で見てみたい

2016年やれたこと

  • 新年初日からておくれた(初日の出号のチケットが無駄に…)
  • メガネっ漢はじめました。本格的に目がだめだ。
  • 生まれ年のウィスキー買った(グレンタレット 1986, 27年物)
  • 同人誌2冊新刊だせた(Plan9 と 802.11それぞれ)
    • 頒布同人誌、昨年比で併せて2.5倍ぐらいの数刷った、個人的にはかなり冒険な数だけどなんとか捌けた。感謝。
    • 念願の、印刷所に印刷お願いした同人誌だせた。仕上がりとっても綺麗。
  • 一陸特とった。4.9Ghz帯で遊ぶためだったのにデバイスはまだない。
  • ジョギングはじめた(頻度は低い)
  • イベント向け無線LAN構築: 8件
    • 主担当1件、お手伝い7件。基本的に無線LANの運用監視中心。
  • はじめてのJANOG参加と沖縄
    • 八丈島と沖縄いった
  • 葉巻始めました
  • 西洋剃刀で髭剃る趣味始めました

2017年にやりたいこと

追記中

  • 厳かに而立を迎える@3月
  • 言語系
    • 仏検(2017/06, 4or3級)とる
    • 独検(2017/06/25, 4or3級)とる
    • 漢語水平考試(12/03, 2級)とる
    • アイスランド語勉強する
    • 仏語で「Le Mythe de Sisyphe」読み切る
  • 一陸技(秋)とる
  • CCNA WIFUNDとる、たぶんCCENTが事前に必要っぽい
  • IEEE WCETうけたい(一陸技が必要で、受験料55k、つらい)
  • 無線LAN利用状況監視の新しい方向性を作る
  • 作る物の半分をgolangにしてみる (from ruby)
  • CAD覚える
    • 3DプリンタでPiZero版キャプチャ箱のケースつくってみる
    • 基板を起こしてみる(quickcharge用)
  • ネットワークアナライザの使い方を覚える
  • FPGAとRFフロントエンドでなにかやりたい(ぼくの考えたさいきょーのキャプチャ箱とか)
  • IndesignまたはScribusへのウスイホン作成環境の移行(vivliostyleでもいいかも): acrobat proからの脱却
  • HarveyOS入門まとめる。今までの内容盛り込みつつ。
  • 今年こそ「Plan9のブートプロセスを見る」の同人誌を作る
  • オペラ「ニーベルングの指環」第三夜見にいく@三月
  • 片方の系の財政健全化
  • 原付免許とる
  • 船舶免許取りたい(2級?)
  • 生活用の和服一式ほしい

論文紹介: “Globally Synchronized Time via Datacenter Networks”

本記事は システム系論文紹介 Advent Calendar 2016の4日目, 12/04 のための記事です.

はじめに

4日目 n_kane の担当分では今年の ACM SIGCOMM 2016 より時刻同期話ということで以下の論文を取り上げます.

セッション自体の括りはデータセンター, 内容としても DC 環境での分散システム向けの時刻同期をターゲットにしています. このあたりは個人的な興味ではなかったのですが, 最近時刻同期関連(GPS, NTP, PTP 等等)を勉強しようと思っておりました. その矢先にこの論文を見つけたため今回取り上げることにしました.

対象としている問題

NTPやPTPをベースにした時刻同期はもはや無くてはならないプロトコルですが, ナノ秒レベルでの時刻同期が必要な場合, 精度に非決定性があるというのが本論文で取り上げ解決策を提示している問題です.

NTPはマイクロ〜ミリ秒, PTPはサブナノ秒の精度で時刻(クロック)同期が可能なプロトコルです. これらのプロトコルでは細かい差異はあるにせよ共に, 2台の計算機の間でRTTを測定し これをもとに一方向遅延(OWD One Way Delay)と相互のクロックの差(Offset)を算出, 時刻やクロックを合わせ, クロック発振器がそれを維持し定期的に再計測を行うという方法で 同期を行います.

この流れの RTT 計測, クロックの維持, 再計測に非決定的な誤差を生む要因がある, と本論文では主張しています. NTP, PTPはともに UDP ベースのプロトコルでありネットワーク帯域を消費しているため 間の経路の経路, 輻輳, 機器類のバッファリングや送受信のスケジューリングによる影響を受けます. ベースとなるRTT計測は往路復路が同じであることを前提としていますが, これが常に満たされるとは限りません. クロックの維持も誤差要因となります. 原子時計と異なり一般的なx86の計算機に積まれたクロックはそれぞれに 一定の誤差を生じながら動くため, 時が進むにつれズレが発生します. この補正のためには頻繁な再計測・再同期を行う必要がありますが, あまりに同期対象や頻度が多い場合に時刻同期に帯域を取られてしまうといった問題があります.

解決策

この論文では時刻同期を Ethernet で直結された2台の計算機間において PHY レイヤで行うことで 前節の問題を解決しようとしています. キモはEthernet で接続された計算機間では「既にNIC同士のクロックが同期されている」という点です. Figure 2 にクロックドメインについての図が掲載されていますが, Ethernetのフレームを送受信するにあたって送信側と受信側は実質同じ回路になっており 送信側のクロックに併せて動作をしていると考えることができます.

このNICレベルでのクロック同期を, システムレベルでのクロック同期に利用するというのが 本論文で提示する手法になっています. この手法を用いたクロック同期として DTP (Datacenter Time Protocol) とそれを実装した 10Gbit Ethernet PHY を取り上げています.

ポイント

この論文で DTP の推しポイントとして主張されているのは以下の3点です.

  1. 802.3プロトコルのハックによるオーバーヘッド実質0のプロトコル
  2. ナノ秒レベルでの同期で誤差が予測可能
  3. スイッチを用いたスケーラブルなクロック同期が可能

1. オーバーヘッド実質0のプロトコル

NTPやPTPと同じく DTP も RTT の計測からの一方向遅延の算出を基本としています. 最終的なクロック合わせをオフセットの計算ではなく「一番速いやつに合わせる」 というアルゴリズムの違いはありますが, やっていることはあまり替わりません.

大きな違いは先にも述べたとおり DTP では Ethernet の PHY レイヤで伝送を行う点です. 具体的には PHY の PCS (Protocol Control Sublayer) のスクランブル/デスクランブル化の直前に, 処理を差し込むことでこのレイヤで伝送されているコントロールブロックに載せて DTPのデータを送受信します.

このレイヤでは実際のデータ(Ethernetフレーム)転送の間にリンク維持やエラー通知を目的とした コントロールブロックの送受信が行われています. このうちDTPが有効なリンクでは Idle キャラクタの部分に DTP のデータを載せ送受信することとしています. PCSの上位レイヤには Idle キャラクタを正しく戻してやることで, Ethernetのデータ転送の帯域を実質的に 使うこと無くDTPのやりとりを行うことが可能となっています.

この方法の利点として Ethernet の伝送を邪魔しないこと, 高頻度にクロック同期が可能であることが挙げられます. Idleキャラクタのコントロールブロックは Ethernet フレームが流れる時はその前後に, 何も流れていない時は継続的に差し込まれるため Ethernet の帯域を消費しません. いわゆる10GbE, 100GbEといった速度はこの制御系の通信を除いたものであるためです. このコントロールブロックは輻輳している場合でも 1280〜7680ns の間隔で挿入が可能です. ワーストケースでも数usの周期でクロック同期を回すことが可能であるため, 精度の維持

2. ナノ秒レベルで誤差予測可能なクロック同期

DTP では同期誤差が「4T」に決定的(deterministic)に収まるように設計されています. ここで T は最も速いクロックの周期であり, 10Gbit Ethernetの場合は T = 1 / f = 1 / 156.25MHz = 6.4 nsとなるため, 25.6ns内に収まることになります.

この誤差予測が可能なのは PHY レイヤで同期しているためソフトウェアスタックが介在しないこと, 直結されているため間に何も入らないことにより誤差導入要素が(ほぼ)無いためです. 遅延要因としてはケーブル上の伝搬遅延やエンドポイントでの処理遅延が存在しますが これらは動的には変化しないと仮定を置くことができ, 事前に予測が可能です 一部 Clock Domaing Crossing, 相手のTXに乗ったクロックと自分のTXのクロック間の 遅延を解決するのにランダム性のある誤差が生じますがこれもどちらか速いほうの1クロック内に 収まるということのようです.

複数のPHYを計算機に挿すことでPTPのBoundary Clockのようにネットワークを跨がって時刻を 同期することも可能です. この場合でも「4TD + 8T」に誤差が収まるとしています. ここで D はホップ数を挿します. スモールワールド現象に則って6ホップ経由すればデータセンターの 全ての計算機にリーチできると仮定すると, どの計算機の間でも 153.6ns 以内に誤差が収まる クロック同期が可能となります.

3. スケーラブルな時刻同期

DTP は Ethernet が直結された2台間で行うことが基本ですが, スイッチがDTPをサポートすることで 2台以上のクロック同期が可能となっています. 前提としてスイッチの全ポートが同じクロックを共有するスイッチチップにより制御されていることが 必須にはなりますが, これを基軸として全ポートと DTP のやりとりを行うことで現在の最速クロックに 合わせるという動作が可能です.

評価

有効性の評価としてこの論文では DTP が PTP と比べて非決定性を抑制できていることを確認しています. PTPでは負荷の状況をなし, 中度, 重度と変えたときに300ns程度内, 25us程度内, 100us程度内と 誤差が大きくなっていきまた定常的にもブレが大きいことが見て取れます. 一方の DTP ではMTU 1500バイトの通常のEthernetややジャンボフレームの場合に負荷を掛けても ワーストケースで 4T = 25.6 ns内に常に収まっていることが確認できます.

まとめとおわりに

ここでは Ethernet の PHY レイヤを用いたクロック同期手法 DTP (Datacenter Time Protocol) についての論文を取り上げました. 時刻同期というよりはクロック同期であり, PTPと比してさらにハードウェアのサポートが必要であること, 同期ピア間でケーブルの直結が必要であることなど制約がより強い手法ではあります. ただし誤差の予測がネットワークを跨いでも可能であり必ずしも局所的にしか使えないといったものでもないようです.

スイッチの実装はまだ構想段階のようなので論文中の前提がフィールドで適用できるかどうかや, DTP を実装する NIC PHY のコストや性能への実際の影響についてはより調査や実験が必要と感じました. 個人的には IEEE 802.11ae の PCS をある意味ハックしているのが面白く感じました. また REFERENCES に時刻同期関連の一通りが並んでいるので大変にありがたい文章です.

後付け: 他の候補

その他, 今回紹介しようと思った候補としては以下に挙げるものがありました.

  • ACM SIGCOMM 2016: Inter-Technology Backscatter: Towards Internet Connectivity for Implanted Devices, Iyer et al (University of Washington)
  • ACM SIGCOMM 2016: Evolve or Die: High-Availability Design Principles Drawn from Google’s Network Infrastructure, Govindan et al (Google/USC)

特に必須ではないらしいけど、ワイヤーアンテナにはバランを噛ましましょうという記述 があったので試しに作ってみた。 無線機側の同軸ケーブルは外部導体が 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円弱?