au Wi-Fi SPOTは2012年3月1日からスマートフォンだけでなく、PCやタブレットなど2台目の端末でも利用できるようになりました。（略）ついカッとなってLinuxから接続できるコマンドラインツールを作りました。GitHubにて公開しています。
という素晴らしい記事を見かけたので、試してみました。が、初っぱなの端末 MAC アドレスの登録が、どういうわけか上手く行かない。
{"code":"S08"}
とか
{"code":"S26"}
とかが表示されて全く動かず、同じようにハマっている人も見かける始末。
レスポンスの内容をscrapeして,次のURLを取得する処理を行っているが、上記の結果なので、URLを設定できず、次のPOSTでエラーとなっている。
code: S26だけでは調査する情報が少なすぎる。一旦、調査は断念。。。
http://peke2peke2.sakura.ne.jp/wpblog/2012/05/10/68/
仕方がないので、しびれを切らして公式の接続ツールを試しつつ、 sniff してみたところ、au の認証側サーバーが「登録するMACアドレスを大文字で書かないとエラーを吐く」という素敵仕様と判明。まさかそんなところでハマるとは…*1。
iPhoneの場合（追記）
iPhone の場合、どうやら購入時点で端末の情報（MACアドレスとIMEI）がKDDIからWi2側へ伝えられているようです。
auのiPhoneを購入したり、交換したりすると、その端末のMACアドレスとMEIＤをauからwi2側に引き渡される。
↓
その端末情報をwi2側で登録する。
↓
その端末からのアクセスにはパスワードなしでwi2のWi-Fi SPOTの門戸を開ける。
このためiPhone購入者は特段アプリ等を入れずとも即通信が可能になるわけですが、おそらく端末枠はAndroid端末と同様に二台に制限されているのではないかなと思います。手元にiPhoneがないので確認できませんが、iPhoneを使ってau IDを取得の上、端末登録状況を確認するとどうなっているのでしょうか。
それにしても、KDDIといい、SoftBankといい、iOS端末ではWISPrを使えないのは何故なんでしょうね？
登録の流れ
au Wi-Fi SPOTにLinuxから接続できるようにしてみた - Gマイナー志向 にも書かれていますが、まずは au 側のサーバーに端末自体を登録してやる必要があります。この作業は1デバイスにつき1度行なってやればよく、この登録作業に対して接続用のIDとパスワードが発行されます。
実際にアクセスポイントに接続する際にはこの接続用のIDとパスワードを用いて認証が行われますが、他のデバイスに対して発行されたID/パスワードの流用はできないため、そもそもデバイスの登録が行われていないと接続すらできない、ということになります。この端末登録作業に「ケータイPC連動設定」がなされた au ID が必要になりますが、必ずしも接続端末はこの au ID に紐付けられた端末でなくとも構いません。
端末の初期登録
つらつら通信を追いかけていくと、結局のところ、登録までは
https://auwifi-signup.auone.jp/su2/?{"mac_addrs":["***大文字MACアドレス***"],"manufacturer":"Windows","model":"7","request_type":"0"}
で一発で通るようです。
別に実際の接続端末のOSが何であれ、後半の Manufacture 等のパラメタはチェックしていないようで、Android 端末を繋いでも問題なく通りました。
このアドレス（「***大文字MACアドレス***」の部分はご自身のデバイスMACアドレスに置き換えてください）に接続すると、自動的に au ID の認証ページである connect.auone.jp 配下のページにリダイレクトされるので、そこで au ID の認証を通してやります。
正常に応答があれば、
{"code":"N22","device_num":"01","max_device_num":"02","passwd":"**PASS**","user_id":"**UID**"}
というような json コードが返ってくるはずですので、これで初回の登録は終了です。ここの "user_id" と "passwd" が使用時認証で必要となるので、書き留めておくこと。
なお、現在の au ID 認証では画像認証が必須となっていますので、 GitHub - matsuu/auwifispot-client: au Wi-Fi SPOT CLI client で公開されているスクリプトでは認証を通過できないと思われます。
端末の登録解除とか
上記サンプルコードでは端末の登録可能台数は2台まで、うち1台目の登録が完了しました（N22）というレスポンスになっていますが、 "request_type" をいろいろ変化させてみると、他にもレスポンスタイプがあることが窺えます。
"request_type" は、
- 0
- 通常登録・ID/パスワードの確認（MACアドレス、Manufacturer、Model 必須）
- 1
- パスワードの変更（MACアドレス必須）
- 2
- 登録ID/パスワードの両変更（MACアドレス必須）
- 3
- 登録端末の列挙
- 4
- 端末登録解除（MACアドレス必須）
というオプションがあるようで、それぞれにレスポンス（"code" 値）も変化するようです。なお、規定台数以上の端末を登録しようとすると、 "E40" というエラーで怒られます。この場合は端末を列挙させ、不要な端末を削除してください。
なお、当然ながらこれらの作業は au id による認証を通過後、Cookie を保持した状態での作業が必須です。また、（カッコ）で記載したとおり、各情報は MAC アドレスをキーとして識別するようです。
使用時認証
au wifi サービスと銘打っていますが、実際には wi2 系 wifi サービスへのローミングサービスとなっています。AP側がマルチSSID対応になっており、回線のバックホールには WiMAX または固定回線を、バックエンド側は KDDI 網で回収しているようで、認証系と設置作業は wi2 もしくは UQ のお仕事のようです。
なので、接続時には、先の登録作業時に回収した接続用 "user_id" に
@au
を付けて認証を受ける必要があります。 @wi2 とかと同じような感じで。
Wifi AP の認証鍵がわからないという場合は、適当に https://play.google.com/store/apps/details?id=jp.co.netvision.WifiConnectWI2&hl=ja でも入れてやれば良いんじゃないでしょうか。インストールしてアンインストールしてしまえば、WEP/WPA鍵だけ残してくれます。
通常、Hotspot 系の AP では、未認証の状態で何かしらのURLを送付すると自動的にログイン認証ページに誘導する仕組みになっていますが、WISPr の良いところは、この仕組みを逆手にとって認証用画面のソース内にコメントなどの形で認証に必要な情報が記載されているという点です。このため、認証プロセスをすべて Web ベースで処理することができ、結果としてクライアント側で Web API 様の処理を行うことが可能になります。
wi2 系サービスの場合
UQ-Wifi も同じく service.wi2.ne.jp ドメイン配下での認証となり、システム自体は同じようです。ログイン | 公衆無線LANサービス Wi2 300 のソースを見ると、このように XML で WISPr の接続情報がしっかりと記載されています。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja"> <head> <!-- ここから --> <?xml version="1.0" encoding="UTF-8"?> <WISPAccessGatewayParam xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.acmewisp.com/WISPAccessGatewayParam.xsd"> <Redirect> <AccessProcedure>1.0</AccessProcedure> <AccessLocation>wi2-0000000-0000-00000000</AccessLocation> <LocationName>wi2</LocationName> <LoginURL>https://service.wi2.ne.jp/wi2net/RLogin/1/?SSID=c0000000000000000000000000000000</LoginURL> <MessageType>100</MessageType> <ResponseCode>0</ResponseCode> </Redirect> </WISPAccessGatewayParam> <!-- ここまで --> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>
au wifi の場合
au_Wi-Fi ではどうやら2種類の認証系があり、 service.wi2.ne.jp ドメイン配下での認証となる場合と、ランダム文字列.wi-fi.kddi.com ドメイン配下での認証となる場合があるようです。
どちらもログインページが表示されないのは同じですが、前者の場合は上述の wi2 系と同様、ログイン先の情報が記載された WISPr コードがページ内に記載されているため、この情報を元にログインを行うことができます。一方、後者の場合、接続を試みると「au 接続ツールを使用して接続してください」というメッセージが表示されるのですが、実は WISPr コードはこのページには記述がなく、このページへのリダイレクト命令（HTTP 302）のレスポンスボディ中に埋め込まれています。通常の HTTP クライアントは 200 OK 以外の異常時にはレスポンスヘッダを優先して読み取ってしまうため、レスポンスボディを読み取ることは難しく、筋の悪い実装と言えるでしょう。
mobilepoint の場合
今回の記事の主旨からは若干ずれますが、 mobilepoint でも wi2 系同様、認証ページ内 body 部に WISPr 用コードが埋め込まれています。
mobilepoint は AP の設置場所によって幾つか亜種があるようで、必ずしも全ての AP で API URL など認証系が統一されているわけではないようです。例えば、 N700 系内の AP では Boingo のログイン URL が提示されていたのに、他のマクドナルド系 AP では提示されていなかったり、ということがあります。
mobilepoint の場合、通常のログインページの遷移先がそもそも WISPr ログイン URL だったりするので、 WISPr ログインに iPhone 契約の認証情報を投げ込むと User-agent の確認が行われるのですが、新幹線内 AP で見かけた Boingo のログイン URL では、 User-agent の確認を省いているようです。このような些細な差異を除けば、概ね認証用ページ内に記述があるというのは共通しているようです。
docomo/mzone の場合
docomo は記事執筆時点では 802.1x のみ対応で、 WISPr 対応という話は出ていないようですが、認証用のページにはきっちり WISPr 用と思われるコメントが記載されています。そのうち対応するんじゃないでしょうか。
追記）対応しました。
で、このようにして得られた LoginURL に先の認証情報を POST してやれば、自動的に認証が通って幸せ、ということになります。POSTのパラメータは、
{"UserName": "hogehoge@au", "Password": "fugafuga" }
をエンコードしてやればOK。というか、 WISPr による認証系ではこの2つの引数は統一しろ、という話になっているようです。
接続認証用Bookmarklet
d:id:RobinEgg:20120626:p1 に記載しましたのでご覧ください。
蛇足
- Lawson Wi-Fi
- 一時期巷を賑わせたローソン Wifi ですが、接続インフラこそ wi2 系なものの、実際には wi2 を GW というかプロキシとして、さらに上流のどこか（おそらく https://wifi.lawson.jp/WiFiApi/wifiAuth.do ）に MAC アドレスと Android ID の登録問い合わせをしているようです。従って、完全にクローズドなネットワークとなっており、こちらを Hack するのは Android 端末の実機でパケットキャプチャするか、エミュレータを使ってじっくり粘るかしないと難しそうです。ただ、一つ気になったのは、接続インフラを wi2 に投げてはいるものの、認証系は独自に構築しているようなので、その辺の法律的な区分けってのはどういうふうになってるんでしょう？少なくともいま手元にある情報だけでは通信事業者とは言い切れないでしょうが、パケットの流れ次第では通信事業者に該当する可能性もあったりするのでしょうか。
- 0001softbank/FON
- Wi-Fi スポット設定ソフトの名称は「jp.co.softbank.wispr.froyo」となっており、 WISPr を使ってはいるらしいのですが、こちらも XML で接続情報が供給されないタイプのもののようです。ただ、Android 端末の場合、認証情報は単純に SIM に記載された電話番号を読み取り、暗証番号と組み合わせて
https://wifiota.sbwifi.jp 以下にあるファイルに契約の有無を問い合わせて確認するというもののようであり、そう複雑なスキームにはなっていないものの、やはり Lawson Wi-Fi 同様に解析は厄介そうです。追記: 推測は間違いだったようです。解析した結果を d:id:RobinEgg:20120829:p1 に記載しました。
