2009年03月: clicklog

2009年03月 13 件

ソフトバンクプリペイドケータイ

2009年03月24日 softbank prepaid cellphone

家の電話として使ってるソフトバンクプリペイドケータイの電話番号の有
効期限が気になったので確認。

確認方法は、1400 にダイヤルしてガイダンスにしたがえばオケ。

ちなみに有効期限は 2009/10/24 でした。

(ところで、2Gケータイの有効期限はいつまでだっけ？)

首都高News 郵送で入手

2009年03月21日 highway

首都高News (1部)の郵送での入手方法

140円の切手
メモ書きでOK
- 首都高News N月号希望
- 氏名
- 住所
- 電話番号

を次の宛て先へ送付。(返信用の封筒とかは不要)

103-0015
東京都中央区日本橋箱崎町43-5
首都高(株) サービス推進部御中

(返信用の切手の代金をその場で計算してるからこういう情報をウェブに載せないのかな)

UQ WiMAX - Windows Vista at オフィス

2009年03月16日 UQ WiMAX

Windows Vista でのインストールは再起動が不要だった(その代わり、モデムを抜き差ししないとネットワークインタフェースとして認識されなかった)

で、港区のオフィスビル21Fでつなごうとしたけどダメでした。「WiMAX に接続処理中です」の状態がしばらく続き、一瞬「接続準備ができました」になるけど、すぐに接続処理中に戻っちゃう。まぁ、高層ビルだし、建物の中だししようがないでしょう。

UQ WiMAX - Windows7

2009年03月16日 Windows7 UQ WiMAX

Windows7 にインストールしようとしたら、

そもそも互換モードじゃないとインストールすらできなかった
インストールしたら起動しなくなって、自動的に修復が始まった

何かおかしかったのかな。また今度試してみよう。

Mac OS X では使えないことが分かってる UQ WiMAX だけど、VMware Fusion 上の WindowsXP で動くならそこで ICS (Internet Connection Sharing) を動かして、Windows に NAT してもらって外に出ればよいだろうと思い立ち試してみた。

始めに普段 VMware Fusion を NAT (VMware Fusion - 仮想マシン - ネットワーク - NAT)で使ってたので、そのまま Windows 内でネットワークアダプタ「UQ」のプロパティから「詳細設定 - インターネット接続の共有 - ネットワークをほかのユーザに…」をチェックして「ホームネットワーク接続」に「en0」(VMware Fusion の提供する仮想 Ethernet インタフェースの名前を en0 としている)を選択した。

すると、en0 のアドレスが 192.168.0.1 になり、DHCP を配り始めた。しかし、ここで問題が。OSX 側ではこの en0 は(VMware Fusion で「NAT」を選んでるため) vmnet8 に接続されているが、VMware Fusion 的にも DHCP が動いてるため DHCP を使ってくれない。強引に vmnet8 に alias で IPアドレスをつけた(192.168.0.100/24)ところ、一応 192.168.0.1 には ping ができるし、外の世界にも ping はできた。dig @192.168.0.1 www.yahoo.co.jp で名前も索けるのだが、通常のアプリケーションは名前解決に失敗してた。当然、/etc/resolv.conf に「nameserver 192.168.0.1」と書いていたが、今時の OSX にそれは通用しないようだ。

しかたなく「"VMware Fusion" "Internet Connection Sharing"」で検索したところ、あっさりこのページが見つかった。いろいろ書いてあるが、要するに、

VMware Fusion でネットワークの設定をブリッジ(VMware Fusion - 仮想マシン - ネットワーク - ブリッジ)にする
AirMac で adhoc ネットワークを作る (すると link up する！)

というだけ。adhoc にすることでリンクが上がり、VMware Fusion 的に en0 が AirMac に接続される。そうすればしめたもの。VMware Fusion 上の WindowsXP が DHCP でアドレスと DNS サーバのアドレスを配布し。AirMac が受け取るまで少し待てば、その後は OSX からも UQ WiMAX 経由で通信ができる。

というわけで VMware Fusion を NAT 箱相当に使い、いつでも OSX から通信する環境ができた。嬉しい。なお、モニター期間は 2009年06月30日まで。それまでに OSX でネイティブに使えるようになるといいな。

ちなみに、OSX 側からだと普通に traceroute できた。

% traceroute -q1 www.google.co.jp
traceroute: Warning: www.google.co.jp has multiple addresses; using 66.249.89.99
traceroute to www.l.google.com (66.249.89.99), 64 hops max, 40 byte packets
 1  vmware (192.168.0.1)  0.886 ms
 2  119.107.200.49 (119.107.200.49)  106.280 ms
 3  172.28.69.12 (172.28.69.12)  116.250 ms
 4  124.211.15.9 (124.211.15.9)  106.647 ms
 5  obpjbb202.kddnet.ad.jp (210.132.126.17)  82.833 ms
 6  otejbb203.kddnet.ad.jp (59.128.4.177)  104.345 ms
 7  ix-ote208.kddnet.ad.jp (59.128.7.138)  123.073 ms
 8  203.181.102.106 (203.181.102.106)  143.022 ms
 9  209.85.241.68 (209.85.241.68)  123.274 ms
10  72.14.236.126 (72.14.236.126)  155.014 ms
11  jp-in-f99.google.com (66.249.89.99)  145.299 ms
%

UQ WiMAX - ネットワーク

2009年03月16日 UQ WiMAX Network bgp

続いてネットワークをもうちょいよく見てみた。

C:\>ipconfig /all

[...]

Ethernet adapter UQ:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : UD01SS WiMAX Wave2 NIC
        Physical Address. . . . . . . . . : 00-1D-93-09-2E-1E
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 113.152.x.x
        Subnet Mask . . . . . . . . . . . : 255.255.255.255
        Default Gateway . . . . . . . . . : 119.107.200.9
        DHCP Server . . . . . . . . . . . : 119.107.200.9
        DNS Servers . . . . . . . . . . . : 119.107.200.23
        Lease Obtained. . . . . . . . . . : 2009年3月15日 21:41:18
        Lease Expires . . . . . . . . . . : 2009年3月16日 21:41:18

C:\>

Point-to-Point リンクだから default gateway があさってのネットワークに向いてても問題なし。ping とか traceroute とかはこんな感じ。

C:\>ping www.google.co.jp

Pinging www.l.google.com [66.249.89.99] with 32 bytes of data:

Reply from 66.249.89.99: bytes=32 time=131ms TTL=247
Reply from 66.249.89.99: bytes=32 time=112ms TTL=247
Reply from 66.249.89.99: bytes=32 time=113ms TTL=247
Reply from 66.249.89.99: bytes=32 time=112ms TTL=247

Ping statistics for 66.249.89.99:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 112ms, Maximum = 131ms, Average = 117ms

C:\>tracert www.google.co.jp

Tracing route to www.l.google.com [66.249.89.147]
over a maximum of 30 hops:

  1   121 ms   127 ms   129 ms  119.107.200.49
  2   103 ms   128 ms   131 ms  172.28.69.12
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5  ^C
C:\>

途中でプライベードアドレスを使ってる。

さて、じゃあこのネットワークはどうやって広告されてるのでしょう？

route-views.wide.routeviews.org> show ip bgp 113.152.x.x
BGP routing table entry for 113.152.64.0/18
Paths: (4 available, best #4, table Default-IP-Routing-Table)
  Not advertised to any peer
  2497 2516
    202.249.2.110 from 202.249.2.169 (58.138.96.143)
      Origin IGP, localpref 100, valid, external
      Last update: Sun Mar 15 08:16:11 2009

  4538 10026 2516
    202.112.60.243 from 202.112.60.243 (202.112.60.243)
      Origin IGP, localpref 100, valid, external
      Last update: Sat Feb 28 09:21:12 2009

  7500 2516
    202.249.2.86 from 202.249.2.86 (203.178.133.115)
      Origin IGP, localpref 100, valid, external
      Last update: Thu Feb 19 10:09:07 2009

  4777 2516
    202.249.2.110 from 202.249.2.20 (210.171.224.6)
      Origin IGP, localpref 100, valid, external, best
      Last update: Thu Feb 19 10:08:55 2009

というわけで KDDI から広告されてます。まぁ、当たり前ですね。
ちなみに途中で traceroute が止まっちゃってるので、外からもやってみた。

[...]
 13 pax-brdr-01.inet.qwest.net (205.171.234.2) [AS 209] 32 msec 28 msec
 14 124.215.192.77 [AS 2516] 32 msec 32 msec 32 msec
 15 pacbb001.kddnet.ad.jp (124.211.34.125) [AS 2516] 24 msec 24 msec
    pacbb002.kddnet.ad.jp (124.211.34.133) [AS 2516] 28 msec
 16 otecbb103.kddnet.ad.jp (203.181.100.185) [AS 2516] 136 msec 200 msec
    otecbb104.kddnet.ad.jp (203.181.100.181) [AS 2516] 200 msec
 17 otejbb203.kddnet.ad.jp (59.128.4.69) [AS 2516] 200 msec
    otejbb203.kddnet.ad.jp (203.181.96.130) [AS 2516] 132 msec 136 msec
 18  *  *  *

いずれにせよダメでした。

UQ WiMAX - インストール

2009年03月16日 OSX WiMAX UQ

UQ WiMAX のモデム UD01SS が届いたので使ってみた。

何はともあれ MBP に挿してみた。

Mar 15 21:12:00 snow kernel[0]: SAM Multimedia: READ or WRITE failed, SENSE_KEY = 0x05, ASC = 0x20, ASCQ = 0x00

とか表示されて使えなかった。(当たり前)
ただ ISO9660 フォーマットの USB メモリ(?)としては認識され、"Volume" という名前で mount された。中身は、

autorun.inf
Files/
Setup.exe
Setup.exe.manifest

(autorun.inf では Setup.exe が実行されるようになっていた)

いずれにせよ動かないので VMware Fusion 上の WindowsXP に認識させてみた。こちらでも、普通に USB メモリとして認識されてる。

まずは、メモリ内にあった Setup.exe を実行。(たぶんこのタイミングで)デバイスの自動認識が始まるがマニュアルにしたがってキャンセル。

普通にドライバのインストールが終わる。

デバイスドライバ上で正しくネットワークアダプタとして認識される。

普通にネットワークアダプタの一覧にも出てきた(ここでは UQ という名前に変更した)

続けて CD-ROM より接続ユーティリティのインストール

何事もなくインストールが終わり、促されるまま再起動するとつながった。

東京都周縁部(一応23区内)の鉄筋マンションの8階、窓から5メートルくらいの場所でこんな感じ(恐らく緑の棒が感度を示してるのだろう。最大でバリ5かな？)

コネクションユーティリティによる表示はこんなもん。

RBB TODAYで計測したら 4.3Mbps くらいだった。

look into ServersMan transactions

2009年03月08日 freebit emotionlink IPv6 VPN iPhone

ServersMan の通信をしばらく Wireshark してみたけど、どこで IPv6 が使われてるのか分からなかった。(なお iPhone は NAT の裏)

流れとしては、

www.freebit.com に接続
/serversman/iphone/checkstatus.txt を GET して status のチェック
snedit.dream.jp に接続して HTTPS でごにょごにょ (たぶんログイン処理)
snel01.dti.ne.jp HTTPS で接続してごにょごにょ
途中から snel01.dti.ne.jp 側が port 9000 と 9001 (どちらも中身は SSL)の通信に移行
その後は port 9000/9001 での処理が続く (サーバ側から定期的に keepalive も行なわれてる)

といった感じ。(port の使い分けはサーバ:9001 → iPhone、iPhone → サーバ:9000 の模様) ちなみに当たり前だけどここまでの通信はすべて IPv4。その後、たとえば http://serversman.net/(iPhone名)/ にアクセスすると、snel01.dti.ne.jp から iPhone にアクセスがあってコンテンツを返送してるようだ。(要するに snel01.dti.ne.jp と serversman.net が iPhone の proxy になってる感じ)

本日時点でサーバについてるアドレスは以下の通り。

snedit.dream.jp	202.216.231.115
serversman.net	202.216.231.116
snel01.dti.ne.jp	202.216.231.117 / 2001:2e8:22:18::117

serversman.net には IPv6 アドレスがついてないんだから当たり前だけど、クライアントとの通信も IPv4。

snel01.dti.ne.jp には IPv6 アドレスがついてるから、もしかして iPhone と、(この proxy 風の)サーバとの間で SSL 内に tunnel が作られて、そこで IPv6 の通信をしてる、ってことなのかな…？一応、ServersMan で「情報」って項目を見ると 2001:2e8:500:29aa::/64 内のアドレスが付いてると表示されるが、外からは ping はできないし、何に使われてるかは不明。

もしかしたら iPhone が NAT の外にいると挙動が違うのだろうか？

余談

こうやってパケットというかトランザクションを見てると、あらためて SSL って煩雑だと思う
iPhone 上での WWW サーバは lighttpd 1.4.19 の模様
ダンプする時は ip.len > 52 が便利。余計な ACK とか見なくて済む
well-known port を使ってない場合は Analyze - Decode As が便利
Wireshark の OSX native アプリケーションは出ないのかな…

awk

2009年03月07日 UNIX CLI awk script

>cat a
A

B

C
>cat a | awk 'NF{print $0}'
A
B
C
>cat a | awk 'NF{print $0}' | awk '1;'
A
B
C
>cat a | awk 'NF{print $0}' | awk '1;{print "x"}'
A
x
B
x
C
x
>cat a | awk '{print (NF ? "[" ++a "]: " : "") $0}'
[1]: A


[2]: B


[3]: C
>cat a
1 2 3
4 5
6
>cat a | awk '{s=0; for(i=1;i<=NF;i++) s=s+$i; print s}'
6
9
6
>cat a
A B C X
D X E
F X
>cat a | awk '{sub(/X$/,"Y"); print}'
A B C Y
D X E
F Y
>cat a | awk '{$2=""; print}'
A  C X
D  E
F 
>cat a
AAA
BBB
CCC
AAA
CCC
DDD
>cat a | awk '! a[$0]++'
AAA
BBB
CCC
DDD
>

FeedBurner to Google

2009年03月07日 blog google RSS

FeedBurner が Google のドメインにマイグレされたけどどうやってるのかチェックしてみた。

>telnet feeds.feedburner.jp 80
Trying 66.150.96.120...
Connected to feeds.feedburner.jp.
Escape character is '^]'.
GET /Clicklog HTTP/1.0

HTTP/1.1 302 Moved Temporarily
Date: Sat, 07 Mar 2009 11:38:54 GMT
Server: Apache
X-FB-Host: jpfeed3.feedburner.com
Location: http://feeds2.feedburner.com/Clicklog
Content-Length: 0
Keep-Alive: timeout=1, max=32
Connection: Keep-Alive
Content-Type: text/plain

Connection closed by foreign host.
>host feeds2.feedburner.com
feeds2.feedburner.com is an alias for www4.l.google.com.
www4.l.google.com has address 72.14.235.118
>host feedproxy.google.com
feedproxy.google.com is an alias for www4.l.google.com.
www4.l.google.com has address 72.14.235.118
>

まぁ、またドメインが変わるのも面倒なので「My Account → MyBrand」でフィードも独自ドメインに変更した。

How to update iPhone apps

2009年03月07日 iPhone app

US/JP アカウントの app が入り交じってると更新できなかった時にやってたこと。

前提

JPアカウントの app は Music/iTunes/Mobile Applications JP
USアカウントの app は Music/iTunes/Mobile Applications US
Music/iTunes/Mobile Applications は空っぽ

実際の手順は、

iTunes 上ですべての app を削除 (ただし「ファイルを残す」を選択する)
Music/iTunes/Mobile Applications US から iTunes の「アプリケーション」へ .ipa ファイルを D&D する (Music/iTunes/Mobile Applications へコピーされる)
Music/iTunes/Mobile Applications US を削除
「アップデートの確認」を実行
再度、iTunes 上ですべての(といっても、今回はまだ片方のアカウント由来の app しか登録されてない) app を削除
Music/iTunes/Mobile Applications を Music/iTunes/Mobile Applications tmp へリネーム
同様に、Music/iTunes/Mobile Applications JP の .ipa ファイルを iTunes へ D&D
Music/iTunes/Mobile Applications JP を削除
更新
Music/iTunes/Mobile Applications を Music/iTunes/Mobile Applications JP へリネーム
Music/iTunes/Mobile Applications tmp から .ipa ファイルを D&D
Music/iTunes/Mobile Applications を Music/iTunes/Mobile Applications US へリネーム
Music/iTunes/Mobile Applications tmp を削除

iPhone App アップデート

2009年03月07日 iPhone app

あれ？いつもはUSアカウントで購入した app を削除してからじゃないとアップデートできなかったのに、今日は普通にアップデートできた。サーバ側で何か修正があったのかな？

IM+

2009年03月07日 apple iPhone Security

iPhone の app「IM+ Lite」を試してみた。と言っても、興味は「サーバに直接つなぐか否か？」だけ。結論は ×。残念ながら別のサーバを介して接続してた。

テスト環境

MacBook Pro の共有で、
- 共有する接続経路を「Ethernet」
- 相手のコンピュータが使用するポートを「AirMac」
にして、iPhone から Wi-Fi で MacBook Pro に接続する。
その状態で en1 を Wireshark で監視する。

テスト結果

IM+ を起動するとまず、igate1.shapeservices.net と sar2.shapeservices.net の名前を索く
sar2 に http で接続し /regServer/registration を GET する
igate1 に接続し(なぜか接続先ポート番号は 443 (HTTPS)なのに SSL は使ってない)、IMEI とか送ってる (符号化されてる風)
すると igate1 がその次に接続する代理サーバの IPアドレスとポート番号を返してくる (「Rdr ip(x.x.x.x m) port(nnnn)」)
もう一度 sar2 の /regServer/registration を GET する (多分、ここまでで IM+ 的セットアップが終了)
先に取得した代理サーバへ接続する (SSL 等は使っておらず、プロトコルも平文)
設定した接続情報が代理サーバへ送られる (サーバ名、ユーザ名、パスワード、SSL 使用の有無など。これも平文。符号化はされてる風。)
(代理サーバがログイン後)buddy の情報が平文で送られてくる (SSL 使用の有無に関わらず)

というわけで、

パスワードが第三者(IM+ の運用者)のサーバへ送られる
SSL されてない

の2点から落第点。(テストに使ったサーバでのパスワードは変更しといた)

しかし、ユーザ名・パスワードを入力させる app は、その扱いがどうなってるか、もっと明記して欲しいものだ…。