hardware, コラム, 失敗談, 歴史, 雑談

注意: 読んでも時間の無駄、思い出話です。35歳未満の方はそっと閉じていただければ幸いです。

15年前 「まぁまぁ」定番のNIC

 10年、いや15年以上前の Linux。コンピュータ屋さん以外にもやっと Linux というものが認知されはじめ、流行のディストリビューションは Slackware から Red Hat Linux へ。「どうやら最近の Linux は結構ちゃんと動くらしいね」という巷での噂 …そんな頃を思い出すモノが会社の廃棄物置き場で発見され、思わず救出しました。

dec21140
DEC 21140

 もしかしてこれは DMM が東京進出した際にはじめて導入されたサーバに入っていたNICかも…?

 これは DEC の 21140 というチップが載った 100BASE-TX の NIC です。tulip というコード名のほうが通りがよいでしょうか。当時 Linux での NIC といえば、カニ(Realtek RTL8139シリーズ), 3com 3c905シリーズ、Intel PRO/100(8255x), そしてこの DEC の 2114x 系列 (tulip/de4x5) がポピュラーでした。他にもあることにはありましたが、Linux においての選択肢は多くありませんでした。

  1. Intel eepro100, 3com 3c905: 高級、ちゃんと動く
  2. DEC 21140: そんなに高価じゃない(6,000円程度と記憶) まあまあちゃんと動く
  3. RTL8139C or lator: 安価(2,000円?), やたらCPUを食う、運が悪いとNICが止まってOS再起動、カーネル刺さる
  4. それ以外: 安価、動くかわからない、カーネル刺さる

 この中で “まぁまぁ” の NIC は DEC 21140, これが定番でした。

安いNICはよくカーネルがpanicした

 安いNICはろくなことがありませんでした。CPUを食う、kernel panic で死ぬのは高負荷時とも限らず再現性が謎、速度が超遅くなる、NICの存在ごと沈黙、たまたま動いていてもカーネルをアップデートするとおかしくなるなどなど。珍しいパターンでは ネットワークに何かしら流れていないとCPUが食われてしまう(トラフィックのグラフと CPU使用率のグラフが対称っぽい形を描く)、などなど、さまざまな珍現象に見舞われました。

 FreeBSDの rl, RTL8139 ドライバのソースに「史上最低のひどいチップだ」のようなコメントが書かれていたことも話題になりました。

dec21140_2
DEC 21140 裏 (ぷらっとホーム)

 なんと、ぷらっとホームのシールが貼られています。DMM が東京進出した際のサーバがぷらっとホームの3Uのものだと聞き及んでおりますので、それに入っていた NIC でしょうか。

 tulip 互換をうたうチップはいくつか存在し(NETGEAR, ADMtek, なんかがあったような), ドライバのソースは互換チップのバグ ワークアラウンドで肥大化していた記憶があります。でも互換チップもちゃんと動かなかったような…

 この頃の PC-UNIX はメジャーな製品(≒ブランド品)しか動かず、貧乏学生のお財布には厳しかったものです。今日 2016 年 では Linux でもだいたいドライバはあるし、カーネルを巻き込んで死ぬようなものはとても少なくなりました。仮想化もあるし。何かハードウェアを買おうとする前に、Linux で動くのかどうか調べまくる人も減ったでしょう。


 ――なんて話を同年代の方々にしたら「チューリップ? そんなのあったなー」「俺は BSD だったし 21140 に特に思いdeはない」など しょっぱい反応……。そんな方々にも以下のカードはお気に召していただけたようです。

adaptec AHA-2940U2W
adaptec AHA-2940U2W

写真を撮ったあとそっと廃棄物置き場へ戻しました…。Interop 2016 でインターネットの未来を見たあと、ちょっと昔の思い出に耽っていました。
「歴史って、人類や生命全体の “おもいで” に違いないのよ」

イベント

会場から見える泊埠頭

ハイサイ! 本日より JANOG38 Meeting in Okinawa がはじまりました。心配されていた天候もいまのところは晴れていますが、とにかく暑い! 台風の前だからかもしれません。会場からは泊埠頭が見渡せます。

プログラムのDay3 には、DMM.comラボから登壇予定のセッションが4つ あります。遠隔からストリーム中継による参加もできますよ。(※都合によりストリーム中継がないセッションもあります)

IMG_1130 IMG_1176

DMM.comラボのブースにもぜひお立ち寄りください。暑〜い沖縄にうれしい、パンチすると冷えるノベルティもご用意しております。よろしくお願いします。

ICTSC, イベント

2/27, 28 に 学生による学生のためのインフラトラブルシューティングコンテスト ICTSC 第5回 cloudpack 杯 が開催されました。

IMG_8397
最優秀賞は早稲田大学のチーム “MWWC” の皆さんです。おめでとうございます!

IMG_8392
優秀賞は東北電子専門学校のチーム “I WAN PUNK MAN’s” の皆さんです。おめでとうございます!

去年の夏に開催された第4回ツチノコ杯での出題を見て「これは楽しそう、大人チームとして解いても絶対おもしろいはず」とブログに書いたら、実行委員会の伊勢さんより「出る???」とのお誘いをいただき、私どもも参加してまいりました。「Exhibition 大人げないチーム」

学生による学生のためのコンテストですが、大人も全員が大人げなくエキサイトして楽しめました。基礎的な問題からマニアックな問題もあり、出題者も選手も皆さん楽しんでやっていましたね(運営側もリアル・トラブルシューティングがありました)。ちょっとひねりが効きすぎている出題もあり、難易度が高くともスキルがあれば必ず解ける問題だとよいのかな、とはいえ現実世界のトラブルシューティングはもっとおかしなものもたくさんありますからね…

大人チームの結果 >>>2位<<< ぐぬぬぬぬ。。MWWCチーム凄い…。

IMG_8382
結果はまあいいじゃないか

# 言い訳すると大人チームメンバーが朝起きられなかったとか、問題の機器の設定が正しく行われていなかったとかでハンデがあったんだ!!!

  • チームワーク大切
  • 何問かが同時に出題され、チームメンバー各位が「私これやりまーす」「これやったらいいんじゃない」のようにふわっと担当を決めていました。ひとつの対象機器に二人以上の担当がつくことがあり、本来ならば作業が衝突しないようコミュニケーションを密にすべきでしたが、ふわっとしすぎて各々が自由に探った結果「あれ? いま何かやった?」のようなことが何度か発生。証拠を保全すべきだったものを復活できない状態にしてしまい、手がかりを掴んだが時すでに遅し、のような典型的ミスをやらかしました。
  • 事前準備大切
  • 選択したコミュニケーションツールが適切でなかったり、「コンソールケーブル持って行ったほうがいいかなぁ」「有線LANインタフェイス持っていったほうがいいかなぁ」「多分あったほうがいいんじゃないかなぁ」← 必須でした。ないと何もできませんw
  • 視野を広く
  • トラシューがテーマのはずなので、出題環境が正常に構成されていればあまり変なことにはなっていないはずなんですよね。だから「こういう問題の該当箇所は難読化するはず」「なんかこの問題だけ難易度が低いから出題意図は別のところにあるはずだ」「このトラブル、どこまでがお題なのか…」などと考えたらだいたい外しています。

いやぁ、お恥ずかしい。大人もヘマします。
すばらしく楽しいイベントでした。次回ICTSC6は大阪開催との噂ですよ。

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

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

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

PAGE TOP