ＭＴＭ０４ 珈琲あります。飲みにきてね。

みなさまご無沙汰しております。

hwhack では春に引き続き、今回もMake Tokyo Meetingに参加．．．の予定だったのですが、２名いる著者が両方とも出張とバッティングしたため、今回は代理の方に参加をお願いしています。

今回の出し物は都内の某研究所で毎日稼働している Twitter対応型コーヒーメーカー「青山みすず」です。このコーヒーメーカーは珈琲を沸かした量とついだ回数を計測することで、あとどれくらい珈琲が残っているかを計れるようになってます。仕掛けなどの秘密は大岡山の会場で。入れ立て珈琲大サービスでお待ちしています！

PS. 特派員からの報告によれば、ＭＴＭではTwitter対応コーヒーメーカー三つ巴の戦いが繰り広げられている模様です。

E-mobile H12HW

E-mobileの電話型端末H12HWを試す機会が会ったのでOpenBSDでのデータ通信を試してみた。H12HWは型番が示すようにHUAWEI社の製品で3.6MbpsのHSDPAに対応している。

結果を共有。

準備

以下のようにsys/dev/usb/usbdevsにProduct ID 0x1008を追加して、usbdevs.hとusbdevs_data.hを再生成しておく。

• product HUAWEI Mobile 0x1008 HUAWEI Mobile

あとはsys/dev/usb/umsm.cのデバイス情報の構造体であるstruct umsm_type umsm_devs[]に

• {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_Mobile}, DEV_HUAWEI},

を追加してkernelをリコンパイルする。

結果

普通にumsm(4)のデバイスとして認識されて、pppdでppp接続も確立できた。

いまはopenbsdの次のリリースに向けた作業が進んでいるので、それが落ち着いた頃にopenbsdにはコミットしておく予定。

自作arduinoのための breadboard hack

lilypadのブートローダをつかえば、ブレッドボードでarduinoを組み立てるのは非常に簡単である。これをさらにonechip arduinoにしてしまうとブレッドボード上のパーツも非常に少なくなるので、小さなブレッドボード上にもかなりの回路をのせることが可能になるだろう。

しかしここで問題になるのは、ブレッドボード上においた AVRのチップのピンと、Arduinoのピンの対応がすぐにわからなくなることだ。何度もやって覚えてしまえればいいのだろうが、間違っていてはあまり意味もないことからこんなhackをやってみた。

ブレッドボードの裏にネットでみつけた ATmega と Arduinoのピン配列の対応表をそのまま貼付けておくだけである。対応図はいろんなところにあるので探してほしいが、たとえばこういうのである。

Make: blog本体ではこんなのが出ていた。この場合チップ単体で使うのならいいのだが、1chip arduinoをつくって部品をチップ上に盛ってしまった場合には下の文字が読めない。

これは undocumented 情報としてMake Tokyo Meeting 03 で初お披露目したのだが、なかなかウケたのでエントリーにもしておくことにする。

UNIX系OS用UQ wimaxドライバの作成(1)

MTM３が終わってから、今度は２週間ちょっとの出張がはいってしまってなかなかblogを書く時間をとれなかったが、いつまでも「MTM3参加中」のエントリがトップなのも寂しいので、最近のwimax関係のアップデートを書いてみる。

UQ Wimax解析の状況

GCT720X系のチップセットを使っているインターフェイス(UD01SSとかUD01OK)の解析はほぼ完了した。要素としては大きく分けると、

• データ通信系（Ethernetフレームを交換する部分）
• 認証系（EAPパケットを処理して通信に必要な鍵を生成する部分）
• ネットワークエントリ系（認証系に加えてwimaxネットワークに参加する部分）
• データストア系（加入者識別子、パスワード、デバイスのX509証明書の処理）
• 管理系（通信状態把握、パラメータ設定）

くらいに分類される。通信に必要なのは最初のデータ通信系の機能だけだが、そこに至るために残りの部分を攻略しなければならかった。「データストア系」はネットワークに接続するために必須の部分であるのに関わらずまったく仕様が公開されていないため、比較的時間を費やしてしまった。

動作検証コード

解析結果はすべてOpenBSD上で検証コードを作成して、実際の動作を確認した。

未知のデバイスのドライバをカーネルドライバとしていきなり実装するのは開発効率が悪すぎる。今回は、ずいぶん前に「ugenでラピッドプロトタイピング(*BSDでUSB）」で書いたようにugen(4)を利用してユーザーランドで実装してみた。さらに、ethernetインターフェイスへのアクセスにもtuntap仮想インターフェイス(tun(4))を用いてユーザランドドライバとして実現した。

ugen(4)を用いてUSBバスをユーザランドドライバに見せたうえで、データフレームをtun(4)でカーネルに挿入するアプリケーションをかけば、実質上ユーザーランドだけでデバイスドライバを書くことができる。

この「ユーザランド」ドライバの構造（概略）を右図に示す。簡略化のために一個のプロセスで全部入りでつくったが、検証用には十分だろう。
機能としては、Wimaxのネットワークをスキャンして、UQ Wimax決めうちで接続処理を行う。デバイスから必要な情報を引きずり出して、認証機構がEAP-TTLS/MSCHAPv2でWimax-PKMv2を処理してログイン＆鍵対の生成を行っている。
うまくつながれば、あとはugen(4)とtun(4)をブリッジしてEthernetインターフェイスとして動いてくれる。普通にDHCPでアドレスをもらって通信できるところまでは動作確認済みだ。
あ、あと、Ethernetブリッジしているのにtapじゃないのは、OpenBSDではtapがtun(4)に統合されているから。tunをLayer2モードで駆動している。

ユーザランドドライバの副次的な効果として「移植性の高さ」がある。たぶん、ほとんど変更しなくてもbsd系のOSでは動くだろうし、ugen(4)をlibusbかなにかに置き換えればOSXやlinuxでも動いちゃうんじゃないかなと予想している。だれかやってみないかな。
ソースは公開する予定だけど、作業の優先順位は要望によって変わります。

今後の予定

ちょっと落ち着いてきたので、解析結果のまとめをつらつらとblogに書きながら、（途中になっている）kernelドライバの作成をやってみようとおもっている。
変なNDAに縛られちゃう前に、知っていることは公知にしておくといいよね？

Make Tokyo Meeting 03 参加中

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

blogでは語れないあんなことやこんなこと、中の人の素顔、途中経過がわからなくなったプロジェクトの進捗など知りたいことがあればぜひおこし下さい。

One Chip Arduinoや USB BlinkM などわかりやすい展示品も取り揃えてあります。

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

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

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

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

おそるおそる電源をいれてみると、うごくっぽい。
電源LEDもつきます。ＡＣアダプタをつなげると「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概略

アタッチしてみてちょっと驚いたのはインターフェイスが７本出現したことだ。一般に3Gモデムは複数（２−３本）のインターフェイスを用意しているが７本出てきたのは初めてだった。

USBディスクリプタを見ると4-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がつながって通信できた。