PORTUS
2013/03/10
WILLCOM PORTUSのUSB
でのネット接続はWindowsのみのサポートのためちょっと調べてみることにした。
USB接続して「3Gネットワーク接続」を選んだ場合には、USBデバイスはベンダーID/
プロダクトIDは0x0619/0x0211で認識されて、二つのインターフェースが提供され、
一つはWindowsのドライバを含んだMass Storage/SCSIでもう一つが、通信用の
Vendor-specificになる。
Windowsのドライバを確認したところQUALCOMMのプロダクトなことが分かった。
どうもUSB接続は3Gモデムとして、処理されていて、市販のUSB-3Gモジュールと
同じようだ。QUALCOMMはUSではGobiというブランド名を使っている。
Gobiの通信仕様はQMIと呼ばれていてUSBの場合はCDCのSendEncapsulatedCommand,
GetEncapsulatedResponseを使って処理される。CDCとは違って、コントロール用の
インターフェースは無く、通信用のインターフェースで処理を行う。
この仕組みは従来のATコマンドでの設定を置き換えることも想定しているようだ。
実際の処理はUSBのコントロール転送でSendEncapsulatedCommandでQMUXという構造
のデータを送り、USBのインタラプト転送でGetEncapsulatedResponseが用意できた
ことが通知されるので、コントロール転送でGetEncapsulatedResponseを受け取る。
受け取ったデータもQMUX形式になる。
処理の流れはクライアントIDを取得して、そのクライアントIDでリクエストして
レスポンスを拾って、クライアントIDをリリースする。
QMIの処理はデバイス管理のDMSやデータ通信管理のWDSなどのカテゴリで分類され
ている。
この処理についてはQUALCOMMがLinux(?)用のオープンソースを提供しているので
おおよその仕様は分かる。またQUALCOMMの
デベロッパーサイトで、登録すると
QMIのドキュメントもダウンロードできる。
ドキュメントには間違いがあったり、また一部のドキュメント(CTL)が公開されてい
なかったりしてなんともちぐはぐだ。
プロトコルも若干冗長な感じだし、オープンソースはおそらく、動作させる為の
最低限のコードで、公開しているオープンソースも見通しが悪いしコードもあまり
奇麗ではない。
オープンソースはQUALCOMMが提供したと思われるコード意外にも、chromiumos用に
リライトした物や、CDC-Etherのコードベースに修正した物や、
libqmiとよばれる
コードなどがあるようだ。
QUALCOMMのオープンソースは必要以上にチェックが入っていたり、TLVの処理を
個別にしていたり、一つのファンクションにあまり関係性の無い二つの機能を入れ
込んでいたり、あまり良いコードとは思えない。
Controlという単語がデーター構造にもリクエストの識別子にもあって、良くないと
思う。またControl FlagsとTranscation IDは合計で3バイトだがCTLのリクエストは2
バイトだったりするのも統一感がなく良くない。クライアントIDという2バイトの
データの中身は1バイト毎に意味があるのも、なんともだ。
QUALCOMMは無線屋としては一流なのかもしれないが、オープンソースやドキュメント
の仕様を見るとインターフェース設計やドライバソフトは三流なのではないかと
思ってしまう。
おおよその処理の流れ
CDCのSendEncapsulatedCommandで以下のQUMXでDMSのクライアントID取得のCTL
リクエストをコントロール転送で送る。
01 0f 00 00 00 00 00 01 22 00 04 00 01 01 00 02
インタラプト転送でコントロール転送が用意できたことが通知される。
a1 01 00 00 01 00 00 00
コントロール転送で、GetEncapsulatedResponseでリクエストを投げると以下の
データが返ってくることがある。なんらかの通知みたいだが分からない。そもそ
もQMIのCTLなリクエストについてはドキュメントが公開されていないので調べる
ことができないのだが。
01 0b 00 80 00 00 02 00 27 00 00 00
なんどかインタラプト転送とコントロール転送を繰り返していると、正常な
レスポンスが返ってくる。このなかのTLVでクライアントIDが通知される。以下の
データでは最後の2バイトでリトルエンディアンなので0x0102(258)になっている。
01 17 00 80 00 00 01 01 22 00 0c 00 02 04 00 00 00 00 00 01 02 00 02 01
上記のクライアントIDを使ってDMSにあるモデルIDをリクエストする。
01 0c 00 00 02 01 00 01 00 23 00 00 00
インタラプト転送でコントロール転送が用意できたことが通知される。
a1 01 00 00 01 00 00 00
コントロール転送で、GetEncapsulatedResponseで以下のデータがレスポンスで
返ってくる。
01 48 00 80 02 01 02 01 00 23 00 3c 00 02 04 00 00 00 00 00 01 32 00 57 58 30
32 53 2d 56 31 2e 30 30 5f 50 57 31 38 57 2d 56 31 2e 35 38 20 20 31 20 20 5b
53 65 70 20 32 31 20 32 30 31 31 20 30 36 3a 30 30 3a 30 30 5d
このデータのTLVの01部分に以下の文字列が入っている。
WX02S-V1.00_PW18W-V1.58 1 [Sep 21 2011 06:00:00]
クライアントIDのリリースをリクエストする。
01 10 00 00 00 00 00 01 23 00 05 00 01 02 00 02 01
インタラプト転送でコントロール転送が用意できたことが通知される。
a1 01 00 00 01 00 00 00
リリースのレスポンスがコントロール転送で返ってくる。
01 17 00 80 00 00 01 01 23 00 0c 00 02 04 00 00 00 00 00 01 02 00 02 01
2013/01/22にリリースされたファームのバージョン
WX02S-V1.01_PW18W-V1.71 1 [Sep 21 2011 06:00:00]
QMI_WDS_GET_PROFILE_LISTのレスポンス
01 22 00 80 01 07 02 01 00 2a 00 16 00 02 04 00 00 00 00 00 01 0c 00 01 00 01
08 70 72 6f 66 69 6c 65 31
QMI_NAS_GET_SIG_INFOのレスポンス
01 19 00 80 03 08 02 01 00 4f 00 0d 00 02 04 00 00 00 00 00 13 03 00 96 14 00
上の値はWCDMAの信号強度がrssiが-106dBmでecioが-10dBです。
純正アダプタで充電してもインジケータがずっと赤のままだったんで修理に出したら、
メーカーでは再現しないが通信異常がありメイン基板交換になり、1.00でも1.01でも
ないファームが入って帰ってきたが、アップデートしたら1.01になった。^ ^;
2013/07/17にリリースされたファームのバージョン
WX02S-V1.02_PW18W-V1.79 1 [Sep 21 2011 06:00:00]
とりあえずgithubに上記を試せるlibusbベースのコードを置いてみた。
https://github.com/yamori813/qmitest