フォーマットは以下の落合先生フォーマットをアレンジしたものを使う。
だいたい以下の項目を埋めるイメージ
1 2 3 4 5 6 7 8 9 10 11 |
|
意外と100個書き出すの結構難しい。欲しいもの並べ立てると早いんだろうけど。
]]>機体筐体はこんな感じ。Cisco Aironet 3602i やらと比べるとだいぶコンパクトでカワイイ。
裏側のネジ4つを外すと表カバー、裏カバー、基板の3つに綺麗に分かれる。分解はしやすい。
アンテナ(基板の表カバー側)はこんな感じ。いわゆる逆Fアンテナの模様。 見ての通りアンテナは2つだけで、2.4/5GHz帯共用らしい。
チップ実装面はこんな感じ。シールドを一部外した状態。 右側のシールド内のチップはAtheros AR9582-AR1A。 左の黒いヒートシンクが付いているシールドからちらっと見えている石はAtheros AR9344-BC2AでこちらはSoC。 前者で5GHz帯、後者でCPU兼2.4GHz帯を捌いてる模様。 中央上部、ACアダプタソケットとEthernetソケットの間にピンヘッダが出ている。 細かく調べてはいないがシリアルコンソールが取れるのかもしれない。
この子はIAPタイプなのでコントローラとしても動作する。ダッシュボードはこんな感じ。 1台だけだからかもしれないがCisco WLCと比べるとだいぶシンプル、というか設定できるところが少なめっぽい。よしなに調整してくれるのかな?
AppRFを有効にしてると以下の様に通信内容の分析がAP/クライアントの単位でできるらしい。
今のところ自宅ではAP機能(アクセスモード)に用はないので、スペクトルもモニターモードで動作させている。 このモードだと「スペクトラム」メニューにて非802.11デバイス一覧や、全チャネルのチャネル使用率&品質が見れるらしい。 なおアクセスモードだと動作中チャネルのそれに限定される。
ところでIAPが一台あれば、Remote APモデルのもの仕入れて繋げて遊べたりするのかな? AP105はヤフオクで1500〜2000円/台の価格で数多く出ており、簡単に中規模ネットワークは組めそう。 なお一部のAruba APは某用途向けにファーム/基板ごと特殊モデルと聞くので対象外になりそうではある。
軽くぐぐってみた限り、以下のスレッドにあるとおりクラスタのAP数上限というのはないらしい。 推奨値128とあるようだがここまで巨大なものを組む予定はないので遊ぶ分には困らなさそう。
]]>JuniperやAlaxala, NEC製品などでサポートされているsFlowプロトコルのサンプルを受信するFluentdプラグインを書きました。
netflowプロトコルについては repeatedly さんが既にfluent-plugin-netflowを公開されています。 今回NECのIXシリーズからフローデータを送りつけたいという要望が某所であったため、実装してみました。 とはいえsflowのプロトコルを捌く部分は別の方のパーサに頼っています。
fluent-gemやtd-agent-gemでインストールするだけです。
1
|
|
設定項目は以下の通りです。 待ち受けアドレス(bind)、待ち受けポート(port)そしてタグ名ぐらいしかありません。
1 2 3 4 5 6 7 8 9 10 11 |
|
実際のテストにはスイッチやルータが必要ですが、手元で簡単に試すために 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 |
|
fluentdの標準出力をしばらく眺めていると、以下の様にフローサンプルが出力されます。この時は *.twttr.com (twitter) への通信がキャッチされたようです。
1 2 3 4 5 6 7 |
|
ネットワーク機器にてよく見られるカウンタサンプルとフローサンプル以外にも、host-sflowはOSやアプリケーションの各種メトリックを集めsFlowプロトコルに載せて送信します。 現状の fluent-plugin-sflow ではカウンタ/フローサンプルのパースしかサポートしていないため、それらのメトリックは空扱いになります(上記5行目)。
三十路初心者を慰めてやろうという心ある方々の援助を募集しております> ほしいものリスト
まだ20代の人はこれを聴くといいよ> 而立〜さよなら20代〜
]]>今回は、また自スペースが西1に戻ってきました。 そのため前回のC90 (西3だった)とはまた様子が異なっています。 比較のために、次はできれば東に割り当てられたいですね。
今回は新要素として以下を追加しています。
FCS badなフレームのDurationがどれくらい正確なのかは今後要検証。 これが正確にとれており、Durationの合計がチャネル使用率と合致するならサンプリング精度が良いという指標になりそう。
また、FCS badなデュレーションと これと、プリアンブルだけの情報が上手く取れると高レートなフレームの流れが
]]>今冬のコミックマーケット91にて、1日目 西1 み-18a “glenda9” で出展するにあたって 自スペースにハニーポット無線LANアクセスポイント(以下 ハニポAP)を立てました。 ここではその提供方法、構成および結果について記述します。
この手のイベントでは「応仁のLAN」といった面白SSIDを告知する遊びをする人がいます。 これに倣って自分のスペース名をSSIDで告知というのも可能ですが、 せっかく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には、Buffalo WZR-HP-AG300H に OpenWRT を載せたものを用いました。
C90で同様の試みをしたときは Raspberry Pi と USB Wi-Fi アダプタを用いていました(以下)。 その際は、混雑している2.4GHz帯でしか運用せず出力も弱めであったため、 あまり接続数を稼げませんでした。
WZR-HP-AG300H は家庭用APとしてそれなりにきちんとしたアンテナを備え、 2.4GHz/5GHz帯の同時運用も可能です。 OpenWRT を導入できカスタマイズ性も高いため今回はこれを用いてハニーポットAPを実装しました。
WZR-HP-AG300Hの消費電力は最大13.2Wであり、付属のACアダプタは定格 12V/2.0A となっています。 通常のUSBモバイルバッテリーではここまでの電圧は出せないため、 簡単にやるにはACが取れる電源などの大きめのバッテリーを用意する必要があります。 これらは価格も高い上にでかいし重いしで大変に邪魔なので、 ここでは以下のページに従ってQuickCharge 2.0対応のバッテリー(今回は AUKEY PB-T4 を利用)から12Vを引き出すようにしました。
なお上記ページのコードでは上手く動かなかったため、 挿入するディレイの長さを変更して運用しています。コードは下記をご参照ください。
後述するとおり 10000mAh のバッテリーで6時間程度は運用できました。 基板に起こすのは間に合わなかったので Arduino そのままとブレッドボードで動かしていました。 たまに結線が外れてリブートしてたり。。。。
簡易キャプティブポータル実現のため、以下の細工を入れています。
dnsmasqのレコード上書き機能を用いて全てのホスト名に対して自分のアドレスを返すことで、 アクセスを自身にねじ曲げます。 現状 /etc/init.d/dnsmasq にて dnsmasq コマンドの引数に以下を 加えてこれを実現しています。本来的には /etc/config/dhcp に list address の 行を追加すれば動くはずですが、上手く動作しないようでした。
1
|
|
キャプティブポータルとして HTTP アクセスを受け付ける側には Apache を用います。 上記 DNS の細工により、HTTP アクセスはこちらに向きますがパスは不定のためリダイレクト等が必要です。 OpenWRT デフォルトの apache では mod_rewrite が使えないため、 AliasMatch でこれを実現します。
1 2 3 4 5 6 7 |
|
これにより全ての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秒に渡って実施しました。
接続しにきたユニーククライアント数は 62 台でした。 この値は、ログ中の接続(Authentication)イベントに紐付くMACアドレスのユニークアドレス数を計上したものです。 なお、いくつかの端末は Authentication Response に対してACKを返せていないため実際にAssociationまで至ったクライアントは 56 台です。
MACアドレスのOUIからベンダ名を引き、分布を図示した物が以下になります。 全体でベンダは10種類でした。コミケという利用環境上、大半がスマートフォンであると推測できます。 この中でも大半が Apple (おそらくiPhone/iPad) と Huawei で占められています。 “IEEE Registration Authority”という名前になっているものがありますが、 一部のスマホでは自社のベンダ名を登録していないためこうなっているようです。
ハニーポットAPでは2.4/5GHz帯でそれぞれ別のSSIDを告知しています。 以下は帯域毎のユニーク接続クライアント数の分布です。 2.4GHz帯は18端末、5GHz帯は42端末と後者に寄っています。 接続イベント数上も2.4GHz帯は 33回、5GHz帯は 63回となっており、 5GHz帯側に接続しにくることが多かったようです。
以下は端末の接続持続時間のヒストグラムです。端末が接続してから切断するまでの期間(秒)と発生回数をプロットしています。 10秒単位で丸めています。大半は1分以内ですが、最長で1030秒(17分程度)の場合もあったようです。 300秒にて山がありますが、これは5分毎に走るGTKの更新失敗やらのタイムアウトに起因するものと推測しています。 移動が激しいコミケのような環境では、接続後そのまま明示的に切断せずにクライアントが離脱することが多いため、 このような傾向があるものと考えています。
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といった乱数要素を含んだ文字列を用いる場合があります。 詳細は伏せますが、今回は以下の様な文字列が検出されました。
上記に挙げたとおり android にてホスト名に機種名を用いている例が4つありました。 以下の通り全てHuawei製品であり、このベンダでは一律このポリシーを採っているのかもしれません。
ハニポAPで動作しているDNSサーバでは期間中に合計556回 DNS クエリを受け取っており、 この対象レコードの内訳は以下の通りです。
合計 123 個の名前にたいしてクエリを受信しました。 以下はその中で回数の多いほうからトップ10をプロットしたグラフです。 connectivitycheck.gstatic.com や captive.apple.com のようにキャプティブポータル検知に用いられるホストが多く現れています。 またプッシュ通知を司るホスト向けの通信が多いことも伺えます。
AAAA レコードへのクエリのみを抽出すると、以下の5ホストに対してのクエリを受信していました。 IPv6はサポートしていないため、一律NODATAを返しています。
名前でねじ曲げられた先のキャプティブポータルに対するアクセスは以下のようになっています。
以下はアクセス数の多いほうから、ホスト名のトップ10をプロットしたグラフです。 やはりキャプティブポータル検知用ホストへのアクセスが多めです。
アクセス数のヒストグラムをURL全体に拡張し、そのトップ10を並べたものを以下に記載します。 全体では31個のURLに対するアクセスを記録しています。
通常のWebアクセスらしきものや、Simejiの通信なども見えますが 大多数はキャプティブポータル検知用のURLに対するアクセスです。
今回検出したアクセス時のUser-Agentは大別すると以下の4種類に分けられそれぞれ一定の役割のもと 用いられているようです。
CaptivePortalSupportは主に captive.apple.com 向けの通信に使われていました。 ただしこれだけ、と言うわけではなく以下の様に CaptiveNetworkSupport系とMozilla系のUser-Agentを交互に利用しているようです。
1 2 |
|
CaptiveNetworkSupportを含むUser-Agent文字列には以下のパターンが存在していました。 WISPrの仕様上、User-Agent文字列は “WISPR!任意の文字列” ということになっているので CaptiveNetworkSupportの文字列の出典および後続する数値列の意味は不明です。
1 2 3 4 |
|
Android向けであると推測される connectivitycheck.gstatic.com等へのアクセスは主に Dalvik系 User-Agent から なされています。が、Apple系とおなじくMozilla系Uer-Agentでのアクセスも確認されています。
1 2 |
|
お次やるとしたらこう工夫しようというToDoリスト
追記中
本記事は システム系論文紹介 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点です.
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の周期でクロック同期を回すことが可能であるため, 精度の維持
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 以内に誤差が収まる クロック同期が可能となります.
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 に時刻同期関連の一通りが並んでいるので大変にありがたい文章です.
その他, 今回紹介しようと思った候補としては以下に挙げるものがありました.
IPoE契約してるとお外から名前で引けるようになるの便利。
]]>Google SpreadSheet は便利だけど、描画の遅延とかが半端ないんでお次は App Engine + BigQuery かな。 ElasticSearch + Kibana でいい感じに横並びなメトリックが掛けるならそれが一番なんだけど…
]]>基本的な作り方は1番目のエントリを丸々なぞった。FT-50-43なるトロイダルコアを使う のが筋らしい。が見つからなかったので秋月のそれっぽいやつで代用した。5番目のエン トリを見ると巻き数にきちんと計算が必要らしいのでてきとう極まりない。
巻いたトロイダルコアはこんな感じ。 なおどこのサイトの記述か忘れたが、撚り線を作 るには電動ドライバに束ねた線の端を噛ませて作ると良いらしいとのこと。 もう一方の 端を手かペンチで保持してゆっくりドライバを回すといい感じに撚れる。
完成したバランはこんな感じ。赤黒のターミナルがアンテナ行き、SMAが無線機行き。
SWR計を持ってないんでどれほどきちんと作れてるのかは不明。
ところで手持ちの受信機で HF 帯まで受信できるの ALINCO の DJ-X7 しかない。早くア ップコンバータが欲しい。
]]>部材 | 品目 | 値段 | 個数 | 用途 | 備考 |
---|---|---|---|---|---|
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円弱?
]]>