2009年5月23日土曜日

Make Tokyo Meeting 03 参加中


表題のとおり 今日からはじまったMake Tokyo Meeting 03 に本blogはhwhack.blogspot.com というまんまの名前で参加しています。本日も多数の訪問者ありがとうございました。

blogでは語れないあんなことやこんなこと、中の人の素顔、途中経過がわからなくなったプロジェクトの進捗など知りたいことがあればぜひおこし下さい。
One Chip Arduinoや USB BlinkM などわかりやすい展示品も取り揃えてあります。

体育館はいってすぐ、blog同様のとってもカオスなブースでお待ちしています。

2009年5月14日木曜日

UQ Wi-Fi Gatewayのバッテリ駆動


(念のために書いておきますが本記述は無保証です。バッテリ系はいろいろと危険があるのでよい子・良い大人の方々はまねをしないでくださいね)

UQ WimaxのWi-FI GatewayのWifiアクセスポイント側(UG01OK)のバッテリを入れる場所を眺めていたら、手元にあったクティオのバッテリがぴったりはいるような気がしてきたので試しにいれてみた。なんかぴったりはいります。ふたも閉まります。ふむ。

おそるおそる電源をいれてみると、うごくっぽい。
電源LEDもつきます。ACアダプタをつなげると「battery」LEDも点灯。充電もしてくれるっぽい。

すぐに切ったのでどのくらい使えるかは調べていませんが、3.7V 1900mAHしかないのであんまり持たないと思います。



OpenBSDでSoftbank C01SWを使う

週末に海外の見知らぬ人から「(俺の)sierra wirelessのHSDPAモデムがopenbsdで使えないんだけど」というメールが届いた。ちょうど他の作業で煮詰まっていたので息抜きに何通かメールをやりとりして、OpenBSDのumsm(4)で動くパッチを作ってみた。先方曰く「ちゃんと動いた!」と報告してくれたが、手元に無いデバイスなので不安は残る。ふと思い立ってgoogleするとSoftBankモバイルのC01SWはSierra wirelessのOEM製品らしい。周りを少し見渡すと持っている人が見つかったので、実際にためしてみた。


Tru-install

C01SWはsierra wirelessの「Tru-install」という機能を搭載している。これは、他の3Gモデムでもよくある「普段はUSBマスストレージのデバイスとしてみえて、そこにデバイスドライバがはいってる。そのデバイスドライバをつかってモデムモードに切り替える」という機能だ。windows以外ではあんまり便利ではないし、自分でモードを切り替えてあげないといけない。

Tru-installのモード変更方法

もうこの手の話は何回もしているので、簡潔にモード変更方法を書いておく。
  • USB requestType = Write/Vendor/Device
  • USB request = 0x0b
  • USB request wValue, wIndex, wLength = 0x1, 0, 0
というコントロールリクエストをデバイスに送ると、デバイスがUSBバスから切り離されて再度認識されたときにはモデムデバイス+マスストレージデバイスの複合デバイスに変化している。上記に対応する関数を抜粋すると、こんな感じ。


#define TRUINSTALL_CHANGEMODE_REQUEST 0x0b
usbd_status
umsm_truinstall_changemode(usbd_device_handle dev)
{
usb_device_request_t req;
usbd_status err;
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = TRUINSTALL_CHANGEMODE_REQUEST;
USETW(req.wValue, 0x1);
USETW(req.wIndex, 0);
USETW(req.wLength, 0);

err = usbd_do_request(dev, &req, 0);
if (err)
return (EIO);
return (0);
}


umsm.cに対する変更の全体はCVSで参照できる。

あと、OpenBSDではsys/dev/usb/usbdevsにこのデバイス用のProduct IDを追加しなければならなった。これは追ってコミットしておく。

C01SW概略

アタッチしてみてちょっと驚いたのはインターフェイスが7本出現したことだ。一般に3Gモデムは複数(2−3本)のインターフェイスを用意しているが7本出てきたのは初めてだった。
USBディスクリプタを見ると4-7本目のインターフェイスはインタラプトエンドポイントを含んでいるのでこれらのどれかが通信用のポートのはずだ。上から試してみたところ、4本目が通信用のポートだった。5−7本目のポートはエコーバックされないがATコマンドに反応しているので何らかの管理ポートだと推測される(詳細は見ていない)。

C01SWで通信する

OpenBSDのkernel ppp実装のpppdを使って通信を試みたところ、さっくりとつながった。
設定は昔「NetBSDでEmobile D02HWを使う(設定編)」で書いた物とほとんど同じで、
  • ifconfig ppp0 create でpppインターフェイスを作る
  • /etc/ppp/peers/に対応する設定ファイル(たとえばsoftbank )を作ってttyU3を通信ポートに設定する
  • ソフトバンク用のユーザIDとパスワードを/etc/ppp/chap-secretに書いておく
だけだった。pppd call softbankだけでpppがつながって通信できた。


2009年5月12日火曜日

E-mobile D12HWとD22HW

E-mobileの最近のモデムを触ってみる機会があったのですこし調べてみた。結果を共有。


触ったのはD12HWD22HWで両方ともHUAWEIのOEM製品だ。D22HWはHSUPAでアップリンクが最大1.4Mbpsまで使えるというのが特徴らしい。

OpenBSDで試してみる

HUAWEIの多くのモデムは同じUSBベンダIDとプロダクトIDを共有しているが、今回もその例に漏れず同じIDを利用していた。OpenBSDで試してみたところ、両者とも標準的なHUAWEIプロトコルでUSBマスストレージモードからモデムモードに遷移するようだ。umsm(4)としてデバイスは認識される。pppd経由でネットワーク接続もできたようなので何の工夫もせずに普通につかえる。

メモ:D12HW

D12HWに関してはUSBのディスクリプタの文字列が壊れている部分がある。利用する分には問題はないがUSBディスクリプタの文字列を信用してデバイス認識時に画面に出力してしまうとなんだかよくわからない文字列が表示されてしまうかもしれない。
しょうがないのでOpenBSDではディスクリプタ中の文字列を信用せずにusbdevsの中の文字列を利用するようにUSB_QUIRKS: UQ_NO_STRINGSを設定しておいた。本来はD12HWだけでこのquirksが使われるようにすべきだがみんな同じベンダIDとプロダクトIDを持っているのでほとんど全部のHUAWEIモデムにこのquriksが適用されてしまっている。


2009年5月10日日曜日

UQ WimaxのUD01SS解析 (4)

前回の続き。

一行まとめ「UD01SSの内部コンソールを取得する」話。

OKIネットワークスが出しているUD01OKの解析をしてみたところ、同じGCTセミコンダクタのGDM72XXを使っている製品なら、ほぼUD01SSと同様な構成になっているのではないかと予測を立てることができた。たぶんGCTセミコンダクタが提供するファームウェアおよびデバイスドライバのSDKがLinuxをベースとしたものになっているのだろう。ということで、今後もGDM72XXを使う製品が出るのなら今回の一連の解析も役に立つだろう、ということでよりディープなところもまとめてみたいと思う。

このエントリではUQのUD01SS(やUD01OKなどのGDM72XXベースのWimaxインターフェイス)内で動いている「Wimaxアプリケーション」の操作コンソールについて説明する。

UD01SSの内部ではLinuxが動いている、というのは(1)で 書いた。汎用OSであるLinuxをファームウェアとして利用している以上、カーネル内部だけではなくユーザランドでも何らかのアプリケーションが動いて いるのは当然だ。解析を進めている途中で、そのアプリケーションと対話的に通信していろいろな情報を取得できるようになった。右にWimaxアプリケーションのコマンド一覧(helpコマンドの出力)を載せる(長いので画面キャプチャ形式)


UD01SSの内部アプリケーション:/usr/wimax

UD01SSのユーザランドとしてWimax関連で動いているのは/usr/wimaxコマンドである。このコマンドがGDM72XXのいろいろな要素(内部の別プロセッサとかで動いているプロセスとか)と通信しながら、ホストインターフェイスを提供している。
ホストPC側にWimaxインターフェイスとしての機能をUSBバスを経由して見せているのもこのアプリケーションで、ホスト側からのコマンドはこのアプリケーションが処理している。さらに管理用の対話的コンソールも提供されている。対話的コンソールが受理するコマンド一覧を上の図に示した。使い方はまだわからないことも多いがUD01SS内部で処理しているWimax関連の機能の内部状態を見ることができるので大変便利だ。
右図の画面ダンプはparamコマンドの出力例(mac addressは隠してある)だ。paramコマンドはデバイスの設定パラメータをダンプしてくれる。Wimaxの物理層まで興味があれば役に立つこともあるかもしれない。
ヘルプ画面にあるshellコマンドは興味深い。/bin/shを立ち上げて(fork & exec)内部のlinuxに対するshellアクセスを提供してくれるはずだが、子プロセスとしてのshellはUSBバスに対する通信機構を持っていないのでこの方法でのアクセスでは使えない。大変残念だがUSB経由(wimaxアプリケーションを経由)のshell取得は原理上無理があるようだ。

Wimaxアプリケーションのコンソールでできること

できることは大体以下の通り。

  • 対話的にコマンドを発行してレスポンスを受け取る。たとえば「version」「param」「dump」コマンドはいろいろな内部状態を出力する。
  • 対話的にコマンドを発行して動作モードを変える。(詳細は不明)
  • メモリ状態などを読み込む(詳細は不明)。発行してもハングアップしてしまう場合が多い。
  • 「log on wimax」コマンドを発行すると、非同期メッセージを受け取れるようになる。たとえば、内部の状態遷移に付随して発生する様々なメッセージを受信できる。さらに「sc」「nds」コマンドでデバグメッセージを出力させることで、もっといろいろなことを教えてくれるようになる。
最後の機能は非常に強力だ。単純なUSBバス解析だとバイナリ列の{コマンド,レスポンス}の組を統計的に解析していって意味を抽出する作業が必要になるが、コマンドに対して人間が読める形のレスポンスや状態遷移のタイミングを取得できればシステマチックな解析が可能になる。

取得できる出力の例
2009/4月のファームウェアアップデート後のUD01SSのVersion

DM> version
version 0.3.8.0 (00030800)
DM> dump ver
FW : Rev=1.6.6.4, 2009/04/03 18:18:00 (build: 2009/04/06 16:58:33)
RF : srf72xx-081025(72050227,0), Default
CFG: PHY=0x602, SPEC=204, CPU=3, SD_AFC, UPT, DNT, ARQ2, IPC, FREQ2.5G, SAMSUNG
MAP: 2009-03-24-1613-WAVE2

ほかにも接続状況なども取得できるが、それらは今後対応した操作を説明するときに説明しようと思う。

アクセス方法(概略)

Wimaxアプリケーションのコンソールに対するアクセス方法の概略を載せておく。詳細はGDM72XX系のコマンド体系をまとめるときに補足する。

GDM72XXのコマンドは、大体
  • 2バイトのヘッダ(Command/Response Type)
  • 2バイトのペイロード長(データ部分だけ。ヘッダ部分は含まない)
  • データ
のTLV形式で定義されている。(USBなのでビッグエンディアン)
コンソールに対するデータ送信は、Type:0x030cで、送信したい文字列に"\n\0"文字をつけてデータとして送信する。
受信は非同期メッセージを扱う場合はちょっと複雑だが、普段はType:0x830dのデータの9バイト目から文字列として扱えばよい。継続行がある場合は文字列の最後が非NULL文字になるので、文字列の最後がNULL文字になるまで繰り返し読み込めば複数行のレスポンスも取得できる。

いまはとりあえずopenbsdのugenで書いたユーザランドアプリケーションで実験をしている。プログラムの長さで3-4KBくらい。もしUD01SSとかで遊びたい人がいたら適当に声をかけてほしい(一人だと飽きそう)。

次回

次回のエントリでは、GDM72XXのコマンド体系について説明しようとおもう。認証部分はそのあとになる予定。

2009年5月9日土曜日

ブレッドボード/arduino用のお手軽ケーブル加工



yuoがまたUSBデバイスの解析という大ネタを連載しているので、その合間にcueのほうは電子工作関連のコネタをひとつ。

パーツをブレッドボードやarduinoに刺すときに、しっかりとした足がついているLEDなどはよいが、センサーなどのようにケーブルを介して接続する必要がある場合には、そのケーブルをどうやってブレッドボードに刺すかを考える必要がある。

よくやる手としてはケーブルをピンヘッダにハンダ付けをするというのだが、これでは量産が効かないし、出来上がりが不揃いになってしまう。四角いピンのピンヘッダはブレッドボードへの刺さりがキツいし、丸ピンのヘッダはピンが細すぎてブレッドボードにはいいが、arduinoなどのピンソケットにはすこし緩い。

そこでちょうどいい太さで先端がピンに
なった圧着端子を探していた。なかなかちょうどよいものがなかったのだが、yuoとアキバを探し歩いた結果、VGAコネクタなどに使うシュリンクDSUB用のピンがちょうどいいのじゃないかという結論に達したので紹介しておく。
千石通商で売られているシュリンクDSUB用のコンタクトピンは5本単位で売られている。CUEは田舎に住んでいて交通費を考えると必要数だけ毎回買うの
も無駄なので100本パックを買っている。このとき 「シュリンク(細い方)」DSUBの「オス」を入手する必要がある。写真とおなじものを手にいれれば間違いないだろう。
千石通商の1Fにほかの端子とともにおいてあるはずだ。残念ながら通販ではシュリンクではないDSUB用のピンしか扱っていないようだ。ちなみにRS232Cなどに使う普通のDSUB用のピンは太すぎてブレッドボードに刺さらない。

これを1本づつ切り取ってケーブルに圧着するだけである。小信号用の圧着端子と同じで、エンジニア社の精密圧着ペンチで加工すればよい。ケーブルはAWG26より細いものがよいだろう。

そして圧着部の保護と絶縁のために熱収縮チューブでくるんで完成である。上手に圧着できれば、サンハヤトの高級なほうの柔らかいジャンパーケーブルのような出来映えになるはずだ。

arduinoとブレッドボードがカジュアル電子工作の主戦場になってきた今日この頃、このピンの価値は計り知れないと思う。ちなみに、arduino(FIO)に刺すとこんなかんじになる。

このピンの問題は、ちょうどいい100milピッチのハウジングがないところではあるが、1本単位でバラバラでもよい用途では非常に便利にかつ美しくケーブルを作ることが出来るのでおすすめである。

UQ WimaxのUD01OK(Wi-Fi Gateway)解析

UQ Wimaxが先日からモニターを開始したUQ Wi-Fi GatewayのWimax通信モジュールであるUD01OKを触る機会があったのでちょっと解析してみた。(モニタ募集は例によって外れた)
UQ WimaxのUD01SS解析 (1)も参照するといいかも。

このエントリの一行まとめ「UD01OKとUD01SSは98%くらい互換デバイス」。

UD01OKの概略

UQのモニタ(と少数の購入ユーザ)に対するWimaxの試験運用が始まってしばらくたつが、よく聞こえてくる感想が「屋外はいいけど、屋内じゃ通じない」「窓際ならいけるが、ちょっと遠ざかるとだめ」といった遮蔽物に対する弱さだ。というわけでこのWi-Fi Gatewayは「Wimaxがつながる窓際まではWimaxで、それ以降は802.11無線LANでつなげてやろう」という製品だ(ほかにも、複数クライアントで同時に利用とかもあるけど、まあどうでもいい)。株式会社OKIネットワークスが製造販売している。
Wi-Fi GatewayはUSB接続にWimax通信モジュールと、それをつなげる無線LANアクセスポイントで構成されていて、Wimax通信モジュール自体はWindowsPCに直接接続して利用することもできるようになっている。この通信モジュールがUD01OKだ。

UD01OKも、最近よくあるUSBの通信モジュールと同様に「ゼロインストール」機能が搭載されていて、最初はUSBマスストレージデバイス(CDROM)にみえてその中に必要なドライバが含まれている。Windowsで利用する際にはそのドライバとユーティリティアプリケーションが必要になる。

UD01OKのハードウェア仕様

USBのデバイスディスクリプタをダンプしてみたところ、UD01SSと同様にGCTセミコンダクタが開発した1チップのWimax SoCであるGDM7205を使っていた。また、Windowsドライバをインストールしてディレクトリを見たところ、ドライバもおおむねUD01SSと同じだった(UD01SSほど無防備かつフリーダムではなくて、ちゃんときれいに整理されていたが)。両社ともGCTから提供されたSDKを用いてドライバを書いていると推測される。

USBマスストレージデバイスからWimaxインターフェイスに動作モードを切り替えるコマンドも同じものが使えた。ざっと見ただけだが、その他USB上での操作コマンド群もUD01SSと同一だと思われる。

UD01OKとUD01SSのドライバは競合

ハードウェア構成がほぼ同一で、ドライバも同等のSDKによって構成されているためか、UD01SSをサポートするためのWindowsサービスとUD01OK用のサービスは競合してしまう。両方同時に使う人はほぼ皆無だと思うがUD01SSをインストールしてあったPCにUD01OKのドライバがインストールできずに一時間ほど悩んでしまった。

相違点・共通点

  • USBのベンダIDとプロダクトIDが異なることくらいでハードウェアとファームウェア構成は大体同じ
  • ユーザIDとパスワードを入れているNVRAMの中の情報がちょっと違う
  • NVRAMの中身のひねり方は共通
  • ドライバの見栄え的な出来や完成度はUD01OKのほうがよさそう
  • 無線デバイスとしての感度もUD01OKがよさそう
  • 大きさはUD01OKがUD01SSより体積比で2倍くらい
  • ファームウェアは両方ともLinux(version 2.6.12-uc0) 
まとめ

というわけで、UD01OKに関してもUD01SSの解析結果を参照するとよいはず。

あと、GCTのチップセット使っているWimaxモジュールは大体みんな一緒かもしれない、と予想できるので解析結果が無駄にならなさそうでほっとした。

2009年5月5日火曜日

UQ WimaxのUD01SS解析 (3)

(2009/5/7 認証フローの図を追加)

前回の続き。
UQのUSB型mobile wimaxインターフェイスであるUD01SSの解析メモ(3)。
今回は「どうやってWimaxネットワークに接続するか?」を説明。

  • 「Linuxとか*BSDでUQ Wimaxを使うのはちょっと敷居が高いので、どう越えるか?」
のバックグラウンドになるかな。

Mobile Wimaxの概略

Mobile Wimaxは下の仕様がIEEE802.16eおよびIEEE802.16-2004として規定され、運用などのルールがWimax Forumによって規定されている中・広域の無線アクセス技術である。802.11シリーズの無線LANと同様にIPベースの通信を前提としたアーキテクチャを持っており、高いコストパフォーマンスと相互運用性といった特徴を持っている。

ユーザからみると、「PCに挿せば動く家の外でも使える無線LAN」として動くことが期待されているわけだが、802.11よりも「セキュリティ」や「認証」といった点で気を使わなければならない点も多い。UQ wimax (Wimax forum Wave2)ではそのあたりをどのようにクリアしているのかをちょっとだけ説明しておく。

Mobile Wimaxネットワークへのログイン

カギとなるのは「認証」である。UQのネットワーク(もしくはUQからMVNOしたキャリアのネットワーク)を利用するためには以下の2つの認証を越えなければならない。
  1. デバイス認証(およびネットワーク認証)
  2. ユーザ認証
前者はそのデバイスがWimaxフォーラムの認証を通っているデバイスなのかを検証し、接続してもよいデバイスかを判断するために利用される。それぞれのMobile WimaxデバイスはX.509の証明書を持っている。証明書はデバイスのMACアドレスをWimaxフォーラムの認証局(CA)でサインしたもので、MACアドレスの詐称を防いでいる。これはWimaxフォーラムで規定されており、EAP-TLSを用いてX.509証明書を相互に交換することで相互認証を行う。

後者は課金のために必要な認証。契約者のIDと認証情報を使って、ネットワークにログインするために必要になる。Wimaxフォーラムでは前者のデバイス認証の結果でネットワークへのログイン処理を行うことも許容しているが、UQではMVNOの一部でAAA(認証)サーバ自体も外部にある設定を仮定しているので、ユーザ認証として独立した認証が必要になる。UQではEAP-TTLSを用いた暗号通信路の上にMS-CHAPv2を使ったuser/passwd認証を行っている。

UQの専用アプリケーションの役割

UQではネットワークに接続する際に専用のユーティリティソフトウェアが必要となるが、このソフトウェアの役割の一つは後者の「ユーザ認証」手続きだ。EAP-TTLS/MS-CHAPv2自体は標準化されたプロトコルなので、UQ全体で一つのアプリケーションで済むんじゃないか?みたいな話を聞いたこともあるが、実はそれは難しい。なぜかというと、各デバイス毎に「ユーザ情報(ID/Pass)」やWimaxの基地局からのEAPトランザクションを扱う方法が異なっているからだ。デバイス依存の差異を吸収する仕組みが存在しない現在では各ベンダ毎が自分のデバイスを扱うユーティリティを提供するしかない、という判断なんだろうと理解している。

UD01SSの認証関連機能

UD01SSでは、Wimaxデバイス認証を外部アプリケーションの助けを借りずに行える。つまりデバイス単体でEAP-TLSの確立および証明書の交換、検証、承認が可能で、外からコマンドを送るだけで自動的に進めてくれる。

ユーザ認証部分はちょっと複雑だ。
UQでは利用者にIDやパスワードを管理させずに「Wimaxインターフェイスをさすだけで使える」運用方法を採用している。そのため、UQネットワーク にログインするためのユーザIDおよびパスワードはデバイス内部のNVRAM領域に保存され、ユーザには見えないように隠ぺいされている。これが複雑さの原因だ。
ユーザ認証機構はWimaxデバイスの外部の「ユーティリティアプリケーション」に存在している。そのためUD01SSではユーザ認証のためのEAPトランザクションをUSBバスを通してホストPCにリレーすることでWimaxの認証サーバ(AAAサーバ)とホスト側の「ユーティリティアプリケーション」間の通信を確立させる。ホスト側のユーティリティアプリケーションはリレーされたEAPトランザクションを解釈してEAP-TTLSトンネルを確立したあとに、「ユーザIDとパスワード」を用いて認証を進める。デバイス証明書やユーザIDなどの情報はデバイス毎に異なるため、UD01SSではNVRAM領域に記録してあるらしい。ユーティリティアプリケーションはNVRAMからデータを読み取って処理を進めている。

認証がうまくいった後

EAPでの認証が成功すると、Wimaxネットワークはそのデバイスが網につながることを許可してくれる。
EAPトンネルはこの時点で破棄してもかまわない。WimaxのPKMの残りの部分はUD01SSの内部で処理されてユーザ側にはその成功・失敗しか通知されない(この辺はまだちゃんと実際に試したわけではないのでぬけがあるかも)。
(2009/5/13補足):ユーティリティアプリケーションのEAPセッションからUD01SS内部のPKMの処理に引き継ぐためにMSK(マスターセッションキー)をデバイス側に引き渡す必要がある。

あとはUD01SSは比較的簡単なEthernetインターフェイスに見える。EthernetフレームがUSBバス上に見えるようになるので、DHCPを行ってIPアドレスを取得して通信を進めることになる。Wimax特有の部分は全部UD01SS側でやってくれるので、ホスト側でやることはほとんどない。この辺はデバイスドライバを書いてみようと思うときには非常に都合がよいところだ。

なんか嬉しくない話

が、いい話ばかりではなかった。
UD01SSでは証明書やユーザIDなどはNVRAM領域に記録されている。が、読んでもすぐにはわからない形式でひねってあり、USBバス上でもその状態でデータが交換されるため、専用のユーティリティアプリケーションでなければ内容を確認することはできない。
つまり
  • NVRAM領域の読み方がわからなければ、正規に提供されているOS以外でのUQ Wimaxネットワークの(マットウな方法での)利用は絶望的
である。それはあんまり嬉しくない。
というわけで、そいつをどうやってやっつけようか?という話になるのだが、しばらくがんばってみたところなんとなく復元する方法を作り出すことに成功した。

次回は、その辺の解析の話につながる部分を書いてみる予定。

UQ WimaxのUD01SS解析 (2)

前回の続き。
UQのUSB型mobile wimaxインターフェイスであるUD01SSの解析メモ。

UD01SSのファームウェア(Linux)を覗く

UD01SSは前回も書いたようにLinux(正確にはuclinux)をファームウェアとして利用している。普通に使っていると「なんか認識まで時間がかかるなあ」と思うが、これも裏でlinuxがブートして頑張っていると思うとちょっとは許せてしまうかもしれない。

今回のエントリでは、FirmwareUpdateとして配布されているUD01SSの内部のファイルシステムを覗いてみる方法を紹介する。

Windowsの場合はProgram Files\UQ\UD01SS\FirmwareUpdate\というディレクトリの下にzImageとramdisk.jffs2が配置されている(OSXの場合はまた別の場所。適当に探してほしい)。zImageが圧縮されたlinuxカーネル本体で、ramdisk.jffs2がUD01SSのフラッシュメモリに書き込まれているルートファイルシステム以下のユーザランドファイルシステムだ。kernelの解析はまたにしておいて、わかりやすいramdisk.jffs2を見てみることにする。

jffs2はlinux(とくに組み込み系)で利用されているファイルシステム形式でフラッシメモリに対する書き込みイメージとして利用される。これを普通のPCで動いているLinuxでマウントして見るためには、以下のような手続きが必要だ。ここでは手元のlinuxはi386系で動いていることを仮定しておく。

問題はUD01SSがARMでファイルシステムのそれに合わせて構成されていることだ。エンディアンを変換してあげないとi386のPCではマウントできない。jffs2のイメージの操作にはmtd-toolsというユーティリティを使えばよい。適当に手順を書くと、


  1. linuxホストにramdisk.jffs2を持ってくる

  2. apt-get instlal mtd-toolsなどでmtd-toolsをインストールする

  3. インストールしたツールでエンディアンをリトルエンディアンに変換する。
    • jffs2dump -v -b -e ramdisk-le.jffs2 ramdisk.jffs2

  4. 必要なカーネルモジュールをロードする。
    • sudo modprobe jffs2
    • sudo modprobe mtdblock

  5. ループバックファイルシステムとしてマウントする。
    • sudo losetup /dev/loop0 ramdisk-le.jffs2

    • sudo modprobe block2mtd block2mtd=/dev/loop0,16384

    • sudo mount -t jffs2 -o ro /dev/mtdblock0 /mnt
これで/mntの下にUD01SSのファイルシステムが見えるようになる。

UD01SSのファイルシステム概略

細かいことまで見たい人はぜひ自分で覗いてみてほしいが、ざっくりとしたところをメモとして書いておく。
  • ユーザーはrootだけ(パスワードはちゃんと付いている)
  • ユーザランドバイナリはbusybox化されている。shもある。
  • メインアプリケーションは/usr/wimaxコマンドらしい。たぶんこれがもう一つのOSで動いているタスク群と通信している。


UD01SSのカーネルイメージ

本当はzImageもばらしたほうがいいが、だいぶめんどさいのでgzipで圧縮された場所を引っ張り出してstringsしたくらいで満足してしまった。だれか挑戦した人がいたら詳細を教えてくれるとうれしいかも。

次回のエントリではWimaxインターフェイスとしての基本動作を書いてみる予定。

2009年5月4日月曜日

UQ WimaxのUD01SS解析 (1)

すこし前だがUQ wimaxが関東圏で商業サービス開始を目前に利用モニターを募集していた。あいにく機材を含めた無料モニターには当たらなかったが、ちょっと興味があったので自前でwimaxインターフェイスを購入してしばらく遊んでみた。購入したのはUD01SSというUSBドングル型のインターフェイス。というわけで、その結果を備忘録としてまとめておこうと思う。

UD01SSの概略
UD01SSは韓国のMODACOM社の製品(日本ではシンセイコーポレーションがOEMで販売)で、韓国ではWibro用として販売されているもの(たぶんMW-U2500と一緒なんではないかと推測)だ。WimaxフォーラムのWave2に適応しているのでUQが提供するネットワークと互換性がある。中身はGCTセミコンダクタが開発した1チップのWimax SoCであるGDM7205が使われている。GDM7205はCPUとWimax Mac, PHYが集積されており1チップで必要な機能を全部提供できる、とのこと。

と、これくらいがWebで調べてみてわかることなんだが、あまり面白くない。わざわざ購入してまで調べてみようと思ったのはもう少し面白い特徴があったからだ。UD01SSで面白いと思ったのは、

  • GDM7205はARM926EJと補助CPU(アーキテクチャ不明)が搭載されている
  • UD01SSの内部OSはLinuxと補助CPUで動くリアルタイムOS(詳細不明)で動いている
  • ソフトウェアでUSBクライアントとして動いているのでUSBデバイスとしての構造は比較的簡単
といったあたりだ。とくに、「中身がLinuxで動いているUSBドングルタイプのARMのボード」が12800円っていうだけでなんかほしくなってしまったのでつい買ってしまった、というのが本音かもしれない。

UD01SSの動作モード

最近よくあるUSBのHSDPAモデムなどと同様に、UD01SSもデバイスドライバが存在しないOSでは自身をUSBマスストレージデバイス(CDROM)に見せかけるようになっている。専用のデバイスドライバがインストールされたあとには特別なコマンドを発行してデバイスのモードをWimaxインターフェイスに切り替える。
最初はUSBのVendor ID:0x1076, Product ID:0x7f40のデバイスとして見えているが、モードが変換されると、Vendor ID:0x1eb8, Product ID:0x1240に化ける。
モード変更コマンドは、右の図のようなUSBパケットを生成して送り込めばよい。デバイスがリセットされて新しいVID/PIDをもったデバイスとして再度バスに出現する。

UD01SSのLinuxファイルシステム

内部がLinuxということは別に隠されているわけではない(宣伝しているわけでもないようだけど)。UD01SSのアプリケーションがインストールされると、Windowsの場合はProgram Files\UQ\UD01SS\FirmwareUpdateというディレクトリが作成される。その中身は
  • ramdisk.jffs2
  • zImage
になっていて中身のカーネルとファイルシステムを覗くことができる。

次のエントリーでこれらを覗いてみる方法を書いてみる予定。