DNS, wifi, イベント

Internet Week 2016に参加してます!

15171040_236303366783504_4489887932392932020_n

インターネットの技術者たちが集まり、最新技術から基礎の話しを持ち寄って喧々諤々するイベントです。
DMM.comラボもインターネットを通じてサービスを提供していることもあり、チームメンバーも興味あるセッションを聞いたり、弊社で使用しているネットワークについてお話しをさせていただきました。

・Wi-Fi”再”入門 見えない電波を知識で見抜く~社会的課題も交えて~
登壇者:熊谷暁

slack-for-ios-upload-1slack-for-ios-upload-2

会場は、ほぼ満員!!
電波を光にたとえWi-Fiの基礎知識から、細かいプロトコルの話、本当は怖いWi-Fiセキュリティ知識について話をしてきました。
とてもボリューミーな内容で、話しきれない!といった様子が印象的でした。
登壇後も参加者さんから質問が飛び交い、盛り上がったセッションでした。

・ネットワーク機器の本当のスペックを見抜く
・DNS DAY
登壇者:高嶋 隆一

slack-for-ios-upload-3

こちらもほぼ満席!
弊社のDNS構成について、お話をさせていただきました。
掴みはもちろん、艦これの秋イベントについて。
会場から笑いが沸き、弊社コンテンツの知名度の高さに驚きました。
セッションは、昨今のセキュリティ問題や、オリンピックなども話題に上がり盛り上がりました。

今回は有料セッションということで、発表資料をすぐに公開することができないのが残念ですが、公開可能になった際は、こちらのブログでお知らせさせていただきます。

また、DMM.comラボでは協賛ブースも出しております。
15284053_236303373450170_116789358700428722_n

会場にいらした際には、お立ち寄りください!

CONBU, wifi, コラム, セキュリティ

くまがいです。CROSS2016 ご来場ありがとうございました。大盛況で楽しかったですね。会場無線 LAN を CONBU で提供していましたので、繋がらない報告がないか Twitter を追っていたら、こんな投稿を見つけました。

WiFi繋いだら現在地が秋葉原になってる #cross2016

CROSS2016 は横浜ですので、位置情報がおかしいですね。

Wi-Fi測位のしくみ

スマホが現在位置を取得する方法のひとつとして、Wi-Fi の BSSID(MACアドレス) を利用したシステムがあります。端末は、周囲に見えている Wi-Fi の BSSID をサーバに送りつけます。するとその BSSID に対応した位置が返ってきます。

簡単な仕組みですが、これを世界中で実現させるには途方もない労力が必要です。位置とそれに対応する BSSID のデータベースを構築するには、測位したい全ての場所へ行って無線 LAN を受信する必要があり、今後も更新していかなければなりません。

スマホが Wi-Fi AP の位置情報を収集している

Skyhook Wireless(2010年頃以前の iOS での利用で有名)は、ウォードライビング、車で移動しながら無線 LAN を受信することによってデータベースを構築したといわれていますが、現在 Google や Apple は、この情報収集をスマホユーザ自身にやらせています。

たとえば iOS では、近くの Wi-Fi アクセスポイントの情報とその位置を端末に保存しておき、定期的に Apple へ送信しています。

Apple は Wi-Fi 測位に関する API や、誤った位置情報の修正、オプトアウトの手段などの情報を公開していません。iOS 8 および iOS 9 のプライバシーと位置情報サービスについて の「Wi-Fi と基地局の位置情報のクラウドソーシングデータベース」で何をやっているのか書かれていますが、これ以外の公式情報は見つけられませんでした。

本当のところ何を送ってるんだろう

ここまでは比較的広く知られていることかもしれません。が、具体的にどのような情報がやりとりされているのかはあまり知られていません。

試しに、手元の iPhone がどんな情報を送っているのか観察してみようと思います。使ったのは (iPhone5s, iOS8.2.1), (iPhone5, iOS9.2.1), Burp Suite 1.6.32 です。ちょっと古い理由は特になく、たまたま手元にあったからです。

観察・収集編

我々の iPhone で収集された Wi-Fi と位置データが Apple のサーバへ送信されていく様子です。
pbcwloc_270_01
おっ、何か MAC アドレスっぽいものを送っているのを見つけた!?

pbcwloc_270_02
うわー! バイナリかよ、解散~ と思いましたがこれは Protocol Buffers でシリアライズされた何かのようです。JSON や XML のような人間にやさしいエンコーディングではないため一瞬諦めそうになりました。

Protocol Buffers はバイナリエンコーディングのシリアライズフォーマットで、データ構造はエンコーディングに含まれません。データ構造は別途 IDL(インタフェース定義言語) の .proto で定義して使うもので、エンコードされたデータからはデータ構造がよくわからないのです。

ちょっと .proto をでっち上げてみました。中を見ても何だか分からない項目がいっぱいあります。いくつかは iOS7 か 8 で増えたようです。

message WiFiAccessPoint {
required string bssid = 1;
optional int32 channel = 2;
optional int64 signal_dbm = 3;
message Location {
required double latitude = 1;
required double longitude = 2;
optional int32 unknown3 = 3;
optional int32 unknown4 = 4;
optional int32 unknown5 = 5;
optional int32 unknown6 = 6;
optional int32 unknown7 = 7;
optional int32 unknown8 = 8;
optional int64 unknown9 = 9;
optional int64 unknown10 = 10;
optional int32 unknown11 = 11;
optional int32 unknown12 = 12;
}
optional Location location = 4;
optional string application = 5;
optional int32 unknown7 = 7;
}
message SmartphoneToAppleRequest {
repeated WiFiAccessPoint ap = 3;
}&

実をいうと、このメッセージは2013年頃(iOS6.0)に一度解析したことがあります。それを使って、今回のブログで気楽なネタにしようと思ったら、内容が丸ごと変わっていて全然気楽じゃありませんでした!!!

この .proto でデコードしてみたところ、以下のような内容を Apple へ送信しているようです。

ap {
bssid: "74:3:bd:28:xx:xx"
channel: 4
signal_dbm: -89
location {
latitude: 35.6897295965
longitude: 139.770113602
unknown10: -1
unknown11: 7
unknown12: 0
}
application: "com.google.Maps"
unknown7: 0
}

このケースでは、収集した約300個の BSSID が Apple へ送信されたのを観察できました。無線LANについては BSSID, チャネル、電波強度らしきものが送信されていて、SSID は送信されていないようです。_nomap は考慮されていないようで、ssid_nomap という SSID を出してみたところ普通に送信されていました。Apple に関しては _nomap は効いていないようです。

lat/lng の座標以外には、位置情報をリクエストしたであろうアプリの Bundle ID らしきものが入っています。自分の場合は他に com.protogeo.Moves や com.google.ingress などが入っていました。

その他に、端末の機種名と OS のバージョンも送っていますね。端末を個別に識別するようなものはなさそうです。HTTP ヘッダにも怪しいものはありません。認証もなく、匿名で突然送りつけているようです。

位置情報が狂う原因

AP を持ってオフィスの引越しをすると、引越し前の位置が表示されてしまうことがあります。オフィスに設置していた AP の BSSID に対応する位置情報が更新・収集されていないのが原因ですが、オフィスはともかく、最近は個人宅ではあまり聞かない現象のように思います。なぜオフィスの引越しでよく起こるのでしょうか?

オフィスには複数の AP があり、複数の BSSID が受信できるとします。すると、引越し以前から近隣にある AP よりそれらを優先して使われてしまうのかもしれません。また、都心のオフィスでは空が開けていない場所が多く、GPS の電波が受信しにくいため、BSSID と位置情報が更新されにくいのかもしれません。

更新に関しても、端末の識別もなく収集しているため、ある程度のデータが溜まって確信度が高くならないと有効にならないはずです。

収集されたデータがどのように運用されているのかは調べようがなく、曖昧な記述になってしまいましたが、きっと大きく外してはいないと思います。

観察・利用編

普通に現在位置を取得するパターンです。iOS で現在位置を取得するアプリ(ここでは Google Maps)を起動してみます。

clls_01_03
BSSID らしきものを送っていますね。これらの BSSID は確かに現在、周囲に見えているものです。

clls_02_03
位置情報が含まれたレスポンスが返ってきました。結構大きいようです。送った BSSID の他にも大量に何かがくっついています。例によってバイナリですが、これも Protocol Buffers ですので解析してみます。

でっちあげた .proto です。

message WiFiAccessPointResp {
required string bssid = 1;
message Location {
required int64 latitude = 1; // * 10e-9
required int64 longitude = 2; // * 10e-9
optional int32 unknown3 = 3;
optional int32 unknown4 = 4;
optional int32 unknown5 = 5;
optional int32 unknown6 = 6;
optional int32 unknown7 = 7;
optional int32 unknown8 = 8;
optional int32 unknown9 = 9;
optional int32 unknown10 = 10;
optional int32 unknown11 = 11;
optional int32 unknown12 = 12;
}
optional Location location = 2;
optional int32 channel = 21;
}

message AppleToSmartphoneRequest {
optional int32 unknown1 = 1;
optional WiFiAccessPointResp ap = 2;
optional int32 unknown3 = 3;
optional int32 unknwon4 = 4;
}

message AppleToSmartphoneResponse {
repeated WiFiAccessPointResp ap = 2;
}

収集編での構造と同じかと思いきや微妙に違う………。lat/lng は float じゃなくて固定小数点に変わっているしタグもずれています。。これも 2013 年頃解析したものとは違います。

デコード結果は以下です。

ap {
bssid: "10:6f:3f:6:xx:xx"
location {
latitude: 3565078352
longitude: 13972113022
unknown3: 42
unknown4: 0
unknown5: 21
unknown6: 14
unknown11: 62
unknown12: 69
}
channel: 3
}

位置情報を取得するのに送信した周囲の BSSID の位置情報は、このようにして返ってきました。lat/lng 以外にも何かついてきているようです。

このケースでは、リクエスト時に BSSID を複数(12個)送信しています。レスポンスには、リクエスト時に送信した BSSID 以外にも周辺の BSSID と位置情報が100個ほど含まれていました。iOS, locationd がこのレスポンスから実際の位置情報をどのように計算しているかはわかりません。

BSSID から位置情報を取得したいならもっと簡単な方法がある

Apple のこれを使えば BSSID から位置情報を取得できる!と思うかもしれませんが、そんな面倒でグレーなことをしなくても、もっと簡単で正当な方法があります。

Google Maps Geolocation API で BSSID から位置情報を取得できます。
geolocation
ブラウザからも使われています。

プライバシーの問題

Wi-FiのMACアドレスはもはや住所と考えるしかない 高木浩光@自宅の日記 2011年11月26日

個人で設置している AP の MACアドレス(BSSID) から位置情報が引けるとなると、BSSID は住所に相当するのではないかという指摘があります。これに対し、Google Maps Geolocation API は「2つ以上のBSSIDが含まれないリクエストでは位置情報を取得できない」としています。

The request body’s wifiAccessPoints array must contain two or more WiFi access point objects. macAddress is required; all other fields are optional.

特定の BSSID から位置を調べようとした場合、その近隣の BSSID なんて事前に分からないので、位置情報が取得できません。これで多少は安全になります。一つの AP が複数の BSSID を吹いているなど、推測されやすい状況はありえますが。

結論

一般的に AP が設置されてもすぐに位置情報に反映されるわけではありませんが、カンファレンスやイベントなどで一時的に設置された AP でも、その情報がたくさんの来場者のスマホから送信されてしまい、それなりに確信度の高い位置情報として扱われてしまうのかもしれません。AP は複数台設置されるため、測位の場合でも優先されてしまうのかもしれません。

今回は Wi-Fi 測位のみを扱いましたが、その他 GPS(GNSS)や携帯電話基地局での測位とハイブリッドになっていることがほとんどであり、その挙動は多様です。大きく位置が狂うことが有り得るのは Wi-Fi 測位の特徴といえます。

他の測位手法については、他の機会に触れたいと思います。
それと Android も調べたかったのですが力尽きました。

wifi, ネットワーク, 勉強会, 運用管理

11/17〜19に行われた Internet Week 2015 にて「失敗から学ぶWi-Fi構築」というテーマで講演させていただきました。Wi-Fi で陥りがちなアンチパターンと、それがなぜ失敗してしまうのか、どうしたら改善できるのかというテーマのプログラムでした。

無線LANに限らず、トラブルシューティングでは「なんか変だぞ?」という直感が、理屈よりも先に働くことがあるかと思います。これは経験や、どういう仕組みで動いているかを知ることによって、なんとなく変だなという直感として意識に上がってくるようになるのではないかと思っています。

電波は見えないし聞こえないけど、それがどういったものかをなんとなく知ることで、無線独特の特性、電波の飛び方や干渉の起こり方をなんとなくでも想像できるようになればと思い、このプログラムでお話しました。資料はのちほど Internet Week 2015 のページに掲載される予定です。

オフィス街と郊外を測定しながら走ってみた動画

プログラムの最後に紹介しました車載動画です。都内繁華街で電波が非常に混み合っているエリアから、電波がクリーンなお台場まで、簡易測定器を積んだ車で移動しながら撮影してみました。

測定器には metageek Wi-Spy を利用しました。この測定器は つながらない無線LAN!?(2/3) 調査編 で紹介したものです。

waterfall_wifi
この画面(Chanalyzer4)は、左右が周波数 (無線LANのチャネル表示)です。上下に分かれていますが、上は現在の電波強度、下はその履歴です(記録したものがだんだん下に動いていくのでウォーターフォールグラフなどとも呼びます)。

このケースでは 1, 6, 11 ch でいわゆる Wi-Fi が利用されているように見えます。それぞれのチャネルの真ん中が凹んでいますが、これが IEEE802.11a/g の特徴です。

Wi-Fi で利用されている変調方式 OFDM は、ひとつの通信を複数のサブキャリアと呼ばれる電波に分割して伝送します。802.11g (20MHz幅) であれば52本のサブキャリアに分割し、ひとつの通信となっています。この真ん中の部分は実装上の都合で通信に利用するのが難しいため、使われていません。このため、中心に凹みが観察されます。

秋葉原から出発し、お台場の暁埠頭まで移動しました。これは2.4GHz帯を観測しています。

  • 無線LANではないと思われる電波がかなり多い(意外)
  • 無線LANだけを拾うアプリ(inSSIDer, WiFi Analyzer等のアプリ)だけでは状況を正しく判断できそうにない
  • 繁華街ではほんの少し移動しただけで状況が大きく変わり、この辺はこういう状況である、等といったことは言いにくい

waterfall2

移動した約50分間のウォーターフォールを一枚に圧縮してみました。繁華街を離れ、海に近づくに従って電波の密度が下がっていき、バンド全体がクリーンになっていくのがわかると思います。

とはいえ、海の倉庫街(特に税関のある辺り)から広域にわたって何だかわからない電波が出ていたりもしましたので、やはり実際に測定してみないとわからない、かつ、この瞬間ではこういう電波状況だったが今後どうなるかもわかりません。突然トラブったりすることもあり得ます。

今度、電波がクリーンそうな熊野に行ってきたいと思います(フレッツが来ていない限界集落)。測定したら面白そうな場所があったらぜひ教えてください! 

CONBU, wifi, イベント

まだまだ新人ツチノコのkumaです。CONBUの一員として参加してまいりました。

Perl…に限らないエンジニア達の巨大な祭り YAPC::Asia 2015 が東京ビッグサイトで開催されました。CONBUは会場ネットワーク構築を担当しました。

同時接続数 約1,200,通算接続端末数 約3,600, UTP配線長約1.6km, アクセスポイント約36台。会場の広さもさることながら、各トラックの部屋がほぼ立ち見の満員御礼で、無線LAN環境としてはハードなものでした。さらにこれらを設営する時間はわずか90分弱、非常にハードでした。事前にAPと譜面台とUTPケーブルのキットを作っておき、よーいドンで一気に配備とケーブルの養生ができるようにチームを計画しました。

LT

動画を、音声ありでごらんください!

Day2のLTでCONBUの設営&撤収デモを行いました。LTが始まってCONBUの紹介後、号令とともに大勢のCONBUスタッフが舞台袖から一斉に出現、舞台上に無線APをライブ設営するという前代未聞のLTで、会場は一気に沸き上がり、一時 Twitter のトレンド入りも果たしたようです。

APIとヒートマップ

assoc-6f-7f
各アクセスポイントごとの接続端末数やトラフィックを眺めていると、来場者の動きがつかめます。たとえば、このグラフ(zabbix)は ある時間帯の 7F, 6F の接続端末数です。縦軸が接続端末数、横軸が時間です(色は各アクセスポイントごと)。最後のメインホールでのセッションが終わると、来場者はホールを出ますので 7F ロビーの接続数がいったん増え、さらに6Fへ移動していくのがわかります。東京ビッグサイト会議棟の構造は上から 7F → 6F → 長いエスカレータ → 2Fとなっていて、いったん6Fを経由するのです。

こういった数値をAPIとして提供し、自由に可視化できたら面白そうだと、つねづね思っていました。手が空いたら片手間に作ろうと思いつつ、毎度ネットワークの構築で手いっぱいになってしまっていたので、今回は片手間ではなくAPIチームを結成してちゃんと作りました。

会場ネットワーク情報取得API「CONBU-API]について

会場毎+AP毎に接続端末数を返すシンプルなAPIです。会場のどこにアクセスポイントが設置されているかを公開していますので 、その付近にどれくらいの端末が接続されているかを見ると、その付近におおよそどれくらいの人がいるのかわかります。

heatmap_sequence
ヒートマップとして可視化したものを、試しにアニメgif化してみました。Day1 の6Fのセッションがクローズし7Fの大きな会場へ来場者が集まっていき、やがて7Fもクローズし懇親会会場へ降りてゆく様子が見えます。

トラフィックもAPIとして提供できれば、Network WeatherMap のような可視化、あるいは、より高精度なヒートマップも実現できそうです。

カンファレンスネットワークの作り方

CONBUよりカンファレンスネットワークの作り方というトークをさせていただきました。CONBUの裏側、カンファレンスネットワークを作ってみたい方、API をいじってみたい方、ご参考にしていただければ幸いです。

トークの感想

実は… 個人的には、聞きたいと思っていたセッションのリストも事前になんとなく考えていたのですが、やはり当日はCONBUで手が空かず、無線状況の測定中に聞くのが精一杯でした。動画が上がるのを心待ちにしております!!

Blogに書くまでがYAPCです。YAPCは無事終了しました。次は 9/5 LL Ring Recursive だ!!

wifi, ネットワーク, 運用管理

調査しに行く

前回の記事: つながらない無線LAN!?(1/3)導入編

無線LANが繋がらなくなっている状態のオフィスに赴き、調査します。

事前のヒアリングでは 「快適に繋がるときと調子が悪いときがあり、混み合う時間帯で特に繋がりにくい」 とのことでしたので、電波が届きにくい箇所があるというより混雑しているのではないかと予想しました。

席数に対してアクセスポイントが少なすぎると思われる地点もあり、収容能力を超えている可能性も考えました。このようなケースでは、利用者が多い時間帯を狙って電波の状況を測定する必要があります。

ツール

Metageek WiSpy

電波を可視化する、周波数帯のなかで電波がどんな強度、密度、タイミングで存在するかを見るツールです(スペクトラム アナライザ)。同じ帯域(2.4GHz, 5GHz)に出ている電波なら無線LANに限らず、電子レンジや Bluetooth, ZigBee, 気象レーダーなどの電波も表示できます。特に 2.4GHz帯(ISMバンド)では、無線LANから存在が見えない種類の電波利用がとてもたくさんあり、互いに衝突するものも多いため、存在を可視化することは大切です。

なんでも受信できますが、その内容をデコードすることはできないため、何の電波か見分けるには慣れが必要かもしれません(最終的にわからないことも多い)。

また、広い周波数帯をスピーディに把握でき、干渉源の把握以外にも役立ちます。inSSIDerのような無線LANのビーコンをスペクトラムに重ねて表示できます。

FlukeNetworks AirMagnet WiFi Analyzer

非常に多機能な無線LANアナライザです。無線LANを完全にデコードでき、具体的な問題の特定に役立ちます。WiSpy が電波の存在を見るツールだとすれば、こちらは電波の中身を解釈できるツールです。

無線LANのトラブルシューティングでは、電波の存在だけを見ればわかる低レイヤな問題と、実際に無線LANの中を見てみないとわからない問題があります。AirMagnet は中身を解析し、膨大な情報を非常に見やすい形に整理して表示してくれます。無線LAN以外の電波を見ることはできません。スペクトラムアナライザよりレイヤが高いツールといえます。

inSSIDer, WiFi Analyzer, WiFi Explorer

もっとも身近な無線LAN調査ツールかと思います。AirMagnet, WiSpy は専用のハードウェアを必要とし、必ずしも導入しやすい価格でないかもしれないのに対し、inSSIDer, WiFi Analyzer, WiFi Explorer は PC やスマホの WiFi デバイスを利用した、無料ないし安価なツールです。

これらのツールで可能なのは、無線LANアクセスポイントの存在の検知とその電波強度を調べることだけです。高密度無線LAN環境で起こりがちな、電波が強いのに速度が遅かったり不安定である状態や、実際にアクセスポイントがどれくらい利用されているかなどを調べたいときにはあまり役立ちません。でも、とても軽くて手軽なので、前述のツールと併用することはよくあります。

他に無料で実現可能な手法として、モニタモードで動作できる無線LANデバイスを Wireshark などで見る方法もあります。その気になれば AirMagnet の一部機能のように無線LANの中身を調べることができますが、深い知識と根気が必要な方法かと思います…。 (トラブルシューティングではちょっとやりたくないですが) 取得したい情報があらかじめ決まっているのであれば、たとえば Python のモジュール Scapy には Dot11 Layer が用意されていますので、ツールを作成して解析することも可能です。


測定結果をいくつかご紹介します。

地点A

high_utilization_slow_datarate_s
遅いデータレートと高すぎるチャネル使用率

遅いデータレート(1Mbps)でチャネルの約74%が使用済になっています。スループットが1Mbpsも出ていません。この状態では遅いながらもかろうじて通信はできていますが、これ以上のトラフィックを流そうとすると、無線LANは切れてしまうと思われます。

このときは、複数のポータブル WiFi ルータが存在したようです。実際にデータがたくさん流れておらず、多くがビーコンとプローブ レスポンスでした。ビーコンとは、アクセスポイントが SSID などを含めた基本的機能を送信し続ける制御トラフィックで、端末はこれを受信するとアクセスポイントの一覧に SSID が表示されます。
データをたくさん流していなくとも、アクセスポイントが大量に存在することによって制御トラフィックでチャネルが使い切られてしまい、ろくに通信ができないという本末転倒の状況にあります。

5GHz_HighUtilization
高すぎるチャネル使用率, W53, W56利用なし

こちらは5GHz帯です。40ch, 48ch のチャネル使用率が高いことがうかがえます。また、52ch以上のチャネルが利用されていません。アクセスポイントは5台以上見えているので、DFSか、と思ったのですが、52ch以上がまったく利用されていないのは不思議です。

※DFS: 52ch以上(W53バンド以上)の無線LANでは、同じ周波数帯を共用する気象レーダ等を検出し、検出された場合はそのチャネルでの電波の送信を停止することが義務づけられています。アクセスポイントは、そのチャネルの利用をやめ、他のチャネルをランダムに選択します。レーダの検出により、利用可能なチャネルが減ることになります。レーダの検出は、窓際や見晴らしのよい場所に設置されたアクセスポイントで起こりやすく、建物の奥まったところでは比較的起こりません。

地点B

2.4G_overlap_s
ノイズが多い2.4GHz帯

有線LANで接続されたPCが多いエリアです。アクセスポイントへの接続端末数は多いのですが、それほどトラフィックは多くありません。しかし、上下フロアおよび外からの電波、野良アクセスポイントによって利用チャネルがオーバーラップしてしまい、干渉しあっています。

問題

  • チャネル利用率が高すぎる
  • 遅いデータレートでチャネルが埋まっている可能性が高い
  • アクセスポイントに対して端末数が多く、収容能力を超えている箇所がある
  • 電波が弱いエリアはほとんどない

測定により、以上のような状況が把握できました。何ができるのか考えてみたいと思います。

無線LANの電波を伝える空間は共有されているため、理想的な状態にできるとは限りません。外や上下フロアなどの自社の管理下にない装置から飛んでくる電波、持ち込まれるポータブル WiFi ルータやテザリングなど。免許不要の無線は、国が電波の交通整理をしないから混信を許容せよ、ということでもあります。できることからやっていこうと思います。

続く

PAGE TOP