{: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円弱?

概要

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

計測対象

今回、計測対象にしたのは以下の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 にネットワークスタッフとして参加, そしてそっちに夢中になっててあんまり本編を聞いていないとかどういうこっちゃという感じではありますが, それはそうとしてそれなりに楽しまさせていただきました. 関係者の皆様ありがとうございました.