インドのプネーでAISのSIM2Flyを使ったみた雑感とか。

仕事でインドのプネーに1週間ほど滞在していました。
Pokemon Goでどうしてもサニーゴを捕まえたかったのと、人とコンタクトをとる手段(主にLINE)が使用不能になると命に関わりそうだったので、事前にAmazonでSIMを購入しました。

使用感

インドだとAirtel回線を使用して繋ぐことになります。使用感ですが、特に問題なく繋がり問題なく使えました。が、4G回線でも遅い気がしました。LINEでもテキストメッセージは問題なく送信できるけど、写真は厳しいといった状態ですね。Amazonのレビューにもある通り、バスでの移動中に時たまエラーで繋がらなくなったりしましたが、機内モードから戻すと掴んだので許容範囲かなという感じです。いつでもどこでもスマホでネットが使える日本のインフラに感謝の気持ちがわきました。

ハードとの相性とか

nexus5, nexus5x, zenfone3, nova liteで試しましたが、nexus5とnexus5xでは2G回線しか掴まないか、接続時にエラーが出て(アンテナのアイコンに×マークが付く)ほぼ使い物にならない状態だったので、このSIMを使用して5と5xをインドに携帯するのはおすすめできません。LGのハードに問題があるのかもしれませんが、はっきりとした原因は不明です。5も5xもどっちも使えなかったのでOSの問題ではない気がします。他の機種では問題なく使えました。iPhoneはわかりません。

インド行った感想

バスで走ってるといたるところにAirtelのお店があってインドすげーなーと思いました。サニーゴは滞在最終日にバスで空港に向かってる途中で根性で捕まえました。全然出てくれなくてだいぶ諦めてたのでめっちゃうれしいです。
Phoenix Market Cityにちょっとだけ寄ったのですが、Pixel2の展示会やってました。触ってる暇がなかったのは残念でした。買って帰ろうかなーと思ったのですが、インドで買っても普通に高い(日本円で8万くらいする)のでやめました。

Pixel2の広告

道路状況が本当に最悪(しぬほど揺れるのとスピードブレイカーの凸段差で酔う)なのと、運転手が普通にアホみたいにスピード出すので死ぬかと思いました。道路に牛も人も普通に突っ込んでくるしバイク乗ってる人ほぼ全員ノーヘルだし車線は存在しないし信号はないしとにかくやべえ。現地の人曰く、プネーはまだましで、デリーが最高にクソらしいです。これ以上クソだったらほんと死ぬのでデリーは行きたくないなと思いました。
あと、滞在最終日の朝にnexus5xが突然うんともすんともいわなくなってブートローダーすら起動しなくなりました。LG製品はもう二度と買いたくないです。

Nature Remoは一度メールアドレスを認証させてしまうと変更時にめっちゃくちゃめんどくさい。

表題の通り、というかガジェット系は不具合あっても割とイライラせずに使用するタイプだと思ってるのですが、これはさすがに改善要求したいレベルで仕様がひどかったです。散々発売延期してコレかよ…。

あらまし

Nature RemoとGoogle Home miniを買ったので、IFTTTで連携しようと思いました。nexus5xでアプリをインストールし、メールアドレスAでRemoのアカウント登録を実施し、セットアップ→家電の登録まで済ませました。
次にIFTTTでGoogle Assistantを認証し、Nature Remoの連携も実施しました。これで晴れて音声で家電が操作できるようになりました。やったぜ。ここまではめっちゃくちゃ簡単でしたし、コーディング無しでここまでのことができるのはかなりすごいです。

問題となる操作

ここまでセットアップしたところで、どうしても他のメールアドレスを使用してRemoのアプリ、及びRemoを使用しなければならない事情が発生しました。メールアドレスAではなく、メールアドレスBを使用して最初から全部やり直します。
とりあえずNature Remoの背面ボタンを押してハードリセットしました。壁に貼ってるので、リセットボタンは背面ではなく側面につけてほしかったです。
なお、以降に書いた操作はnexus5x 1台で行っています。

何が問題になるか

  • Nature Remoのアプリにサインアウトの方法がない。(少なくともAndroidアプリにはない)

単純にアプリをアンインストールするだけだと設定値が残存するため、アプリデータを削除してからアンインストールしないとログアウトできません。というか登録済みのアカウントってどこで削除すればいいんでしょうか…。

  • IFTTTとConnectする時に、Connect先のRemoアカウントが古い方になる

  • OAuth認証時に、認証先のRemoアカウントがわからない

IFTTTとRemoの連携をIFTTTのServicesから削除した後、RemoにConnectしなおす場合、ブラウザでOAuth認証するアカウントの対象が古いメールアドレスになります。TwitterのようにOAuth認証画面で認証先のアカウントを確認+変更できれば良いのですが、アカウントがどれなのかもわからないし、認証画面でログアウトもできないので、仕方なくブラウザのキャッシュを全消しして対処しました。
これがかなりクソで、Connect後にServicesを確認しないとどのRemoアカウントと連携してるのかわからないので、古い方のRemoアカウントと連携しているのに気づかず、いつまでたってもRemo側の設定値がIFTTTから読めなくてめっちゃくちゃイライラしました。30分くらいハマった時点でやっと気づいたのですが、ユーザのせいって言われると納得行かない仕様だと思いました。

想定していない操作だったのかもしれませんが、メールアドレス変わったときとかどうすればいいのかわからないし、改善してほしいです。

上記仕様とアプリ自体が初期のPokemon GOレベルで不安定なのを除けばRemo自体は便利です。エアコンも簡単に制御できますし、IRKitで問題だったLEDもまぶしくないし、早くREST API公開してほしいなぁと思います。

tag.retrorocket.biz(はっしゅたんぐら。)のデータが飛びました。

物理的に壊れたのとバックアップも取ってなかったので復旧できません。ほんとすいません。
tag.retrorocket.biz(はっしゅたんぐら。)については利用者が片手で数えるくらいしかいないので、Raspberry Pi 3で運用していたのですが、引っ越しの時にSDカードがぶっ壊れたようでサルベージすらできませんでした。
とりあえずサービス自体はさくらVPSに移行しましたが、IFTTTで同じことができるはず(実際にできるかどうかは試してません)なので、今後はIFTTTの使用をおすすめします。

【雑感】Fiddlerを使ってHuawei nova liteのパケットをキャプチャした。

結構前からnova liteがBaiduと通信してると話題なのですが、2chのスレを見てもほぼまともな情報が得られないのと、ぐぐっても結局通信内容が不明のままだったので、諦めて自分でキャプチャすることにしました。
飽くまで私の持ってる端末・環境での観測結果なので、ご自身の端末がどのような通信をしているのか知りたい方は、ご自身でパケットキャプチャされることをおすすめします。
Wiresharkを使っても良かったのですが、手元にFiddlerの入ってるマシンしかなかったのでFiddlerを使いました。Androidでのパケットキャプチャ用の設定は以下の記事が分かりやすかったです。
Android端末上のHTTP/HTTPS(SSL)通信内容を傍受・解析する方法

観測対象

Huawei nova lite/PRA-LX2C635B160
(現在地が中国以外だと通信しないという話らしいので、情報を載せておくと、)位置情報設定は「高精度」に設定してあります。高精度じゃないとPokemon GOできなくなるので。

観測方法

1時間程度、スリープしないようにして端末を放置。

結果

1時間内で3回 www.baidu.com 宛にGETでアクセスをしていました。(HTTP宛で、クエリパラメータはなしです。)
あと、端末電源ON時に必ずbaiduと通信する、という話も見かけたので何度か電源ON時のパケットもキャプチャしましたが、いずれもbaidu宛の通信は見つかりませんでした。

以下リクエストのキャプチャ結果(3回とも全部同じでした)

GET http://www.baidu.com HTTP/1.1
Charsert: UTF-8
Accept-Charset: utf-8
Content-Type: application/x-www-form-urlencoded
contentType: utf-8
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; PRA-LX2 Build/HUAWEIPRA-LX2)
Host: www.baidu.com
Connection: Keep-Alive
Accept-Encoding: gzip

ちなみに肝心のレスポンスですが、Fiddlerは504を返してきました。うーん…。

[Fiddler] ReadResponse() failed: The server did not return a response for this request. Server returned 0 bytes.

名前解決用にリクエスト飛ばしてるのかもしれないですが、情報がなさすぎて憶測の域を出ませんね。
(24時間くらいがっつりモニタリングしたら何かわかるかもしれないですが、)1時間程度ではよくわかりません、という感想です。
Baiduと通信してるのは確実なことがわかったので、購入はあんまりおすすめできません。

追記(2017/08/20)

Fiddlerのようにローカルプロキシを挟むとローカルプロキシが解釈できないレスポンスがエラーになるので、Wiresharkを使おうとしたのですが、どう頑張っても家のWi-Fiでモニターモードが使用できなかったため、諦めてtPacketCaptureを使用してキャプチャしました。

3時間キャプチャして10回baidu宛の通信を確認しました。以下リクエストです。10回とも内容は全部同じでした。

# 103.235.46.39 宛に通信。
Hypertext Transfer Protocol
    GET / HTTP/1.1\r\n
    Charsert: UTF-8\r\n
    Accept-Charset: utf-8\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    contentType: utf-8\r\n
    User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; PRA-LX2 Build/HUAWEIPRA-LX2)\r\n
    Host: www.baidu.com\r\n
    Connection: Keep-Alive\r\n
    Accept-Encoding: gzip\r\n
    \r\n
    [Full request URI: http://www.baidu.com/]
    [HTTP request 1/1]
    [Response in frame: 471]

以下レスポンス。値がユニークっぽそうな箇所は念のため伏せました。

Hypertext Transfer Protocol
    HTTP/1.1 302 Found\r\n
    Cache-Control: no-cache\r\n
    Connection: Keep-Alive\r\n
    Content-Type: text/html;charset=utf-8\r\n
    Date: Sun, 20 Aug 2017 14:29:54 GMT\r\n
    Location: https://m.baidu.com/?from=844b&vit=fps\r\n
    P3p: CP=" OTI DSP COR IVA OUR IND COM "\r\n
    Server: apache\r\n
    Set-Cookie: BAIDUID=C438EAAB0EFE52A771xxxxx:FG=1; max-age=31536000; expires=Mon, 20-Aug-18 14:29:54 GMT; domain=.baidu.com; path=/; version=1\r\n
     [truncated]Set-Cookie: H_WISE_SIDS=118416_114550_117615_118309_117044_114744_118507_100100_118270_118057_xxx...
    Set-Cookie: BDSVRTM=42; path=/\r\n
    Tracecode: 1794964229xxxxxx\r\n
    Tracecode: 1794926598xxxxxx\r\n
    Traceid: 1503239394xxxxxxxxxx\r\n
    Content-Length: 0\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.189395000 seconds]
    [Request in frame: 469]

似たような通信がないかぐぐると2chのg07スレが見つかりました。
goo g07 Part3 [無断転載禁止]©2ch.net

13 SIM無しさん (オイコラミネオ MMf6-0Bqe)2017/03/29(水) 16:32:10.03ID:8pI43FAvM
GPSの関係でBidouにアクセスが発生する端末が
あると聞いたが、広告騒ぎとは関係なさそうだけどこの通信が必要な理由はなんだろう

Source 103.235.46.39  (BAIDU-HK)
Dustination (略)

HTTP/1.1 302 Found
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html;charset=utf-8
Date: Wed, 29 Mar 2017 05:57:17 GMT
Location: https://m.baidu.com/?from=844b&vit=fps
P3p: CP=” OTI DSP COR IVA OUR IND COM ”
Server: apache
Set-Cookie: BAIDUID=(略):FG=1; max-age=31536000; expires=Thu, 29-Mar-18 05:57:17 GMT; domain=.baidu.com; path=/; version=1
Set-Cookie: H_WISE_SIDS=102569_108266_100043_102435_103300_111882_112106_107313_114130_115245_115110_115055_115244_115044_114797_114513_114998_114330_114535_115031_114276_110085; path=/; domain=.baidu.com
Set-Cookie: BDSVRTM=81; path=/

gooのg07ってcovia製ですよね。あるぇー…。
これ以上調べても新しい情報が見つからなさそうなので私は調査を降ります…。まさに「何の成果も!!得られませんでした!!」って感じですね。何のために通信してるのか全くわからん。

追記(2017/09/17)

Huawei nova lite/PRA-LX2C635B170にアップデートしたところ、6時間観測して1度もbaiduとの通信を検出しませんでした。位置情報をOFFにしても検出しなかったのでかなり謎いです。
しれっとバグを直したとか、通信しないようにしたとかそんな感じでしょうか。如何せん公式に発表もないですし、怪しいことには変わりないので、購入はあんまりおすすめできません。BlueBorneのパッチもいつくるかわからないし…

retrorocket.bizのSSL証明書を再発行しました。

SSLサーバ証明書再発行のお願い – さくらのサポート情報
retrorocket.bizも対象なので再発行しました。これから3年間分無料とはありがたいです…。期限ギリギリまで発行を粘ってちょっとでも証明書の有効期限を伸ばそうかと思いましたが、引き伸ばしてるうちに対応を忘れてしまいそうなのでやめました。
nginxの場合、ssl_certificateに中間証明書を設定しないとサーバから中間証明書が送付されないのですが、完っ全に失念してまして30分くらい本気で悩みました。次の移行時にまた忘れそうですね。

再発行に至った背景は以下の記事がとてもわかりやすいです。
Symantecが再びGoogleの信頼を失った件についてのメモ – Technically, technophobic.
個人的に「シマンテックの言い分が大変うんこである」以外の感想はないです。ブラウザベンダー側が拒否らないと改善されないのもひどい。でもお金払っちゃったから使います。

retrorocket.bizのSSL証明書をラピッドSSLに移行しました。
去年くらいにラピッドSSLに移行したものだと思っていたら2年前でビビりました。

とりあえずOCSP Responseが返ってくるかは確認しました。

$ openssl s_client -connect retrorocket.biz:443 -status -servername retrorocket.biz < /dev/null | head
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA
verify return:1
depth=0 CN = retrorocket.biz
verify return:1
CONNECTED(00000003)
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 04F2100E425F1B9605707A171B87FDED0C1A9B92
    Produced At: Jul 20 09:29:11 2017 GMT
    Responses:
DONE

問題ないですね。