Saturday, September 27, 2014, 14:14 - Misc
Posted by ELIN
vCenter Server 5.5(以下vCS)でvCSが作ったオレオレ証明書ではなく、オレのオレオレ証明書を使おうとしたら色々と大惨事になった
そもそもvCS 5.5は5.1とはMajor Versionこそ一緒だが、全く別物の構造のようで5.1の情報はアテにしてはいけないことに気付くのに時間がかかった

各種証明書は探せば簡単に見付けることができる
しかしESXiのようにrui.*を入れ替えればいけるんじゃね?という安易な発想を行動に移すとその瞬間に再インストールが確定する
vCSの証明書を正しく入れ替えるにはお経のような長くて面倒くさい意味不明の手順を正確にこなさなければいけない
もし手順を1つでも間違うとその瞬間に再インストールが確定する

さて、証明書を入れ替えるにはvCenter Certificate Automation Tool 5.5(以下vCCAT)を使用する
このツールに関わる情報は
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2057340
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080418
http://d.hatena.ne.jp/ogawad/20130524/1369355700
https://sites.google.com/site/63rabbits2/virtual/vmwareview/vcenter-server/vc_setting
等、どれも内容はほぼ同一だがともかく

簡単に目を通すとおかしいことに気付く
vCCATそのものの情報というよりは証明書そのものに関わる情報が大半を占めていて、肝心のvCCATを使用する部分がこれらを読んでもイマイチイメージできない
従ってどの程度のコストで本当に要件が達成できるのかが予測できないままやることになる

結論から言えばvCCATは署名要求を簡単に作成できる機能と、各種サービスの証明書の更新を一応行うことができる
この更新は署名要求の手順を飛ばしても可能で、つまり既に署名された証明書も更新に用いることも可能だ(と思う、未検証)

大まかな流れはまずvCCATで各種署名要求を作成する
この各種というのは通常であれば
・Single Sign-On
・Inventory Service
・vCenter Server
・vCenter Orchestrator
・Web Client
・Log Browser
・Update Manager
の7種を指す
これら全ての署名要求を承認したら各自身の証明書、及びルートCAまでの証明書を合わせたファイル、いわゆるチェイン証明書を作成した上で各サービスへ"認証し、証明書と鍵のファイルを指定"し更新作業を行う
これはつまり最低でも7回の同じことを繰り返すという頭の悪い作業をするということになる

それでは実際の手順
今回の要件となるのはオレオレ認証局が既に署名しているオレオレ中間認証局がvCSの7つの署名要求を承認し、その証明書を使用すること

最初にvCCATを持ってきてC:\vCCATに展開し、署名要求の作成を行う
ssl-updater.batを管理者権限で実行して"2. Generate Certificate Signing Requests"を選択した後、1~7(8は恐らく不必要だが)までの7回、全て同じことを行うという頭の悪い方法で作成する
このとき入力するパラメータに関してはssl-environment.bat(の281行以降)を変更することである程度簡略化することはできる

このような頭の悪いことをやっていると頭が悪くなってしまうので、ssl-environment.batを編集した後に管理者権限で実行したcmd.exeにて
> cd C:\vCCAT
> (ECHO 2&(FOR /L %I IN (1,1,7) DO @ECHO %I&FOR /L %J IN (1,1,9) DO @ECHO;)&ECHO 9&ECHO 9) >input.tmp
> ssl-updater.bat <input.tmp

と、すれば頭の悪い作業を回避できる
ただ一度ファイルに書いているのがこの方法の頭の悪いところで、これはcmd.exeの"SET /P VAR="の動作の頭の悪さが原因なのだが、もしこれを回避できる方法を誰か知っていたら教えて下さい

次は作成した署名要求を承認するのだが、この機能は前述しているURLを見ればわかる通り、頭の悪いvCCATにはない
ただvCCATはopensslのバイナリを含んでいるので、1つ1つファイルを移動(選択)して1つ1つ署名した後にそれらを1つ1つ移動(保存)する、というようなとてつもなく頭の悪い作業を行う必要はない

このopensslで署名作業を行いにはいくつかの準備が必要になる
vCCATはopensslのバイナリこそ含んではいるが、openssl.cfgを含んでいない
従ってこれを入手する必要がある
> powershell (New-Object System.Net.WebClient).DownloadFile(\"http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=apps/openssl.cnf;hb=f71d59c70ed65beaa51de719848901284bb1fd04\",\"$pwd/tools/openssl/openssl.cnf\")
このようにwget的なことを実行する

そして要求されるディレクトリとファイルを一時的に作成し
> MKDIR demoCA\newcerts
> COPY /Y NUL demoCA\index.txt
> ECHO 01 >demoCA\serial


オレオレ中間認証局の証明書と鍵を持ってきてC:\vCCATに置く
ファイル名はica.crtとica.keyとし
> SET CA=ica
> FOR /D %I IN (requests\*) DO (ECHO y&ECHO y)|tools\openssl\openssl.exe ca -in %I\rui.csr -keyfile %CA%.key -cert %CA%.crt -out %I\rui.crt -config tools\openssl\openssl.cnf

これで全ての署名要求が承認され、同ディレクトリ以下に証明書が作成される

そしてそれらの証明書チェインを作成する
証明書チェインはルートCAまでの証明書全てを含む必要があるので、今回の場合はオレオレ認証局の証明書も持ってきて、これをca.crtとした上で
> SET CHAIN=ica.crt ca.crt
> FOR /D %I IN (requests\*) DO @(FOR %J IN (%I\rui.crt %CHAIN%) DO @tools\openssl\openssl.exe x509 -in %J) >%I\chain.pem

これで各証明書チェインが作成され、証明書の更新準備が整った

さて、肝心の更新作業となるが、これは今までで最も頭が悪い
vCCAT(ssl-updater.bat)を実行し、1を選択した後、今回は全ての更新作業を行うので8を選択する

何か理解不能の出力が出てくるが、これは何なのかというと作業順番である
つまり18の作業順番を正しく行わなければ爆発して二度とログインできなくなって再インストールすることになるので、なんと作業順番を表示してくれるわけだ
明示しておくと作業順番を表示してくれるだけで、他は何もしてくれない
メインメニューの3以降を総当たりで全て手動で実行しなければならないという、とてつもなく頭の悪い方法で更新しなければならないというわけだ

更にその内容も非常に頭が悪い
何か行おうとする度に証明書とその鍵のパス、管理者アカウントとそのパスワードなど、同じ内容を延々入力し続けることを要求される
例えば入力のログを取るとこのような感じになる (テストされたものではないので、間違っても流さないこと)
入力内容はssl-environment.batを編集することで入力を簡略化できるとは言え、それを踏まえても頭が悪いに尽きる
しかし色々と考えはしたものの、他に有効な方法があるわけでもないのでssl-environment.batを編集してお茶を濁すことになるのだが……

編集すべき項目を挙げると
・*_cert_chain
・*_private_key*
・sso_admin_user
・vc_username

このうち証明書関連に関しては、もし記述した手順通り作業を行っていて、かつ証明書を生成したときと同一のプロセスのcmd.exe(要するに閉じていない場合)が使用できるならば
> CMD /V:ON /C FOR %I IN (sso is vc vco ngc log-browser vum) DO @(FOR /D %J IN (%CD%\requests\*!%I_organizational_unit_name!*) DO @ECHO SET %I_cert_chain=%J\chain.pem^&IF "%I"=="is" (ECHO SET %I_private_key_new=%J\rui.key) ELSE ECHO SET %I_private_key=%J\rui.key) >>ssl-environment.bat
このような雑な方法で書き足すことができる
もしこの方法が使用できないなら
> FOR /D %I IN (requests\*) DO @ECHO %CD%\%I\chain.pem&ECHO %CD%\%I\rui.key
このように出力させ、素直にコピペで対応する

最後のvc_usernameに関しては
rem # Example:
rem # vc_username=administrator

と、書いてあるもののsso_admin_userと同じ値の"administrator@vsphere.local"とするのが正しい
語弊があるが、ともかく初期状態ならば正しい

またsso_admin_userで毎回の入力を省けるものの、パスワードの方は内部的にsso_admin_passwordとsso_master_passwordが使用されているが、これは迷惑なことに毎回クリアしてくれるので、インストール直後の状態だとクソどうでもいいポリシーによってただストレスを倍増させるだけのクソ長いゴミのようなパスワードを入力し続けるという頭の極めて悪い作業を強制されるので、先に"a"とかにしておこう

あとは頭の悪い手順に従って頭の悪い作業を1つのミスもなくこなせば無事証明書は更新される
1つでも間違うと死ぬ

ちなみに
 Review the `Prerequisites for Installing vCenter Server' secion in the vSphere Documentation Center.
ERROR: One or more required parameters are not set or have invalid values:
- The leaf certificate doesn't have any CN or subjectAltName that matches any known IP address of the current machine. Rejecting the chain. To skip this check, set the `ssl_tool_no_cert_san_check' environment variable to 1.

このようなエラーで弾かれる場合は英語で書いてあるとおりssl_tool_no_cert_san_checkを1にしよう
それ以外のエラーで弾かれる場合はもうそれ死んでるから再インストールしよう
1 comment ( 3552 views )
Tuesday, September 23, 2014, 09:45 - OS / Unix, *BSD, Solaris
Posted by ELIN
検索しても同じ問題に直面しているという情報はあれど"これだ"というような明確な回答が見当たらなかったので、普通にやったら何の問題も無く解決できるような簡単な話なのかなあ、と思いつつ似たようなことをやっている情報を見付ける
http://dokuosan.net/zousan/nikki277.html
http://uenomemo.blog31.fc2.com/blog-entry-405.html
http://www.ellinikonblue.com/blosxom/UNIX/NAS4Free/20140312NAS4FreeCompile.html
これらを読む限りは至って普通の方法で動かすことが出来そうではある

pfSense 2.1.5はhttps://doc.pfsense.org/index.php/PfSense_and_FreeBSD_Versionsによると8.3-RELEASE-p16であるので、その環境を作成する
これには8.3のインストールの"Choose Distributions"で"5 Kern-Developer"を選択し、インストール完了後に
# freebsd-update fetch
# freebsd-update install

とし、再起動すればよい (実際には再起動せずともソースコードは8.3p16になっているのでその必要はないが)

もし
# freebsd-update install
Installing updates...install: ///usr/src/crypto/openssl/ssl/s3_cbc.c: No such file or directory
done.

このようなエラーが出る場合は
# mkdir -p /usr/src/crypto/openssl/ssl/
ディレクトリを作成することで回避できるので、作成後にもう一度実行する

さて、8111Gのドライバはこれを書いている現在最新が186なのだが
# cp rtl_bsd_drv_v186 /usr/src/sys/dev/re
# make -C /usr/src/sys/dev/re
Warning: Object directory not changed from original /usr/src/sys/dev/re
@ -> /usr/src/sys
machine -> /usr/src/sys/amd64/include
:> opt_bdg.h
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c if_re.c
if_re.c: In function 're_attach':
if_re.c:2983: error: 'PCIER_LINK_CAP' undeclared (first use in this function)
if_re.c:2983: error: (Each undeclared identifier is reported only once
if_re.c:2983: error: for each function it appears in.)
if_re.c:2984: error: 'PCIEM_LINK_CAP_ASPM' undeclared (first use in this function)
if_re.c:2986: error: 'PCIER_LINK_CTL' undeclared (first use in this function)
*** Error code 1

Stop in /usr/src/sys/dev/re.

雑な方法だがともかく、コケてしまう

少なくともこの定数は
# find /usr/src/sys|xargs grep PCIER_LINK_CAP
というようなことをしても見付からないのでどうしようもない

このようなとき、別のバージョンを試すというのが定石だが、Realtekは最新版の186しか配布していない
ところがダウンロードの際のFTPをちょっと覗いてみると、実は172-186の各種を見付けることができる
全ては試していないが、ともかく結果としてmakeが通せる最も新しいバージョンは184であることがわかっているので184を手に入れる
ただFTPを覗くのは少々面倒なので……
http://b.mikomoe.jp/download/1411430971/attach/rtl_bsd_drv_v184.tgz

makeの前に必要ならばバックアップし
# find /usr/src/sys/dev/re -type f|xargs -I % mv % %.bak
実際にmakeする
# fetch http://b.mikomoe.jp/download/1411430971/attach/rtl_bsd_drv_v184.tgz
# tar zxvf rtl_bsd_drv_v184.tgz
# cp rtl_bsd_drv_v184/* /usr/src/sys/dev/re
# make -C /usr/src/sys/dev/re

と、して完成
バイナリは/usr/src/sys/dev/re/if_re.koなので、これをpfSenseのほうへ移動する

if_re.koは/boot/kernel/if_re.koに配置し、そしてドライバをロード
# kldload /boot/kernel/if_re.ko
これで8111Gがきちんと認識され、動作するようになる (たぶん)

そして最後に/boot/defaults/loader.confの
if_re_load="NO" # RealTek 8139C+/8169/8169S/8110S
この項目を"YES"に変更する
ちなみにYesやyesではなく、確実に大文字で"YES"とすること

またNanoBSD版では/がroであるため、この作業の前後に
# /etc/rc.conf_mount_rw
...
# /etc/rc.conf_mount_ro

として、一時的に書き込めるようにする必要がある
add comment ( 4177 views )
Sunday, September 21, 2014, 07:51 - Misc
Posted by ELIN
pfSenseが起動しなくなったのと、それに付随して起こった問題の検証の簡易的な記録

1. pfSenseが起動しない

・HDDが壊れている
/がmountできないようなので、応急処置としてUSB-Flashへ換装することで解決
その後検証してみたが、実際ファイルシステムが破損しており、まやbad sectorも多数存在しているようでddでも読み切れない

2. クラッシュする

換装後から再現
現象としてはオーバーヒートしたときのように電源から落ちる

・/usr/local/sbin/check_reload_statusがおかしい
プロセスがCPU100%でスタックしており、そのタイミングでクラッシュしているようなので若干怪しいと睨む
プロセスを殺し、バイナリを移動することで起動しないようにするなどの対策をとるが、改善しない
そもそもこのバイナリは必要なものなので、起動しないようにする手段をとった場合、pfSenseそのものに問題が生じる

・2.1.5がおかしい
換装時に2.1から2.1.5へバージョンアップしており、前述した/usr/local/sbin/check_reload_statusも含めて発生している問題かと推測したが、結論からいえば違う
2.1.xやi386など試してみるものの、改善はしないが、2.1のほうが頻度が低いように感じられた

・メモリが壊れている
換装やスロットの変更などしてみたが改善しない
これが原因ではない

・オーバーヒートしている
CPUの温度、そのヒートシンクやケース内の温度は問題は見られないが、ブリッジチップに関してはヒートシンクが相当熱くなっていたため、ファンを直風があたるよう設置
しかし現象の頻度が下がらないどころか、後述する別の問題も発生するようになる

3. 電源が入らない

語弊があるかもしれないが、現象としては一時的にファンこそ回転するものの即座に停止する
少なくともBIOSに到達できない状況

・電圧不足
電源はCS-01B-B/300V2に付属していたDPS-300AB-9Cを2007年から継続して使用しており、経年劣化により電圧降下が発生していると推測
5Vには若干その気配こそあるものの4.86Vで少なくとも即座にクラッシュするような電圧ではないし、3.3Vと12Vに関しては何の問題もない
しかし前述しているファンの追加以降再現するようになった問題であるため、疑いを晴らせず、最低限度のパーツを残して全て取り外す
一応電源が入らない、という問題こそ回避できたが以前クラッシュするという問題に関しては変化せず

4. em*が落ちる

ネットワークカードを一時的に抜いたような現象

・ネットワークカードが壊れた
今回の問題によって電源のon/offの頻度が相当高くなっているので、それが原因で壊れたという可能性を推測
しかしこの現象は2枚ささっているIntel GT DP 82546GBの両方にて発生していたので、推測が正しいとは思えない
ただ問題が発生しているのは事実なのでBroadcom NetXtreme BCM5703へ換装

5. bge*が落ちる

換装した以降に再現するようになった
em*と同様にネットワークカードを一時的に抜いたような現象

・M/Bが壊れた
換装したカードで発生したわけではないため、同様にネットワークカードが壊れたという可能性も否定できないが、4枚全てが電源のon/offで壊れるという確率と、またこのM/Bはpfsenseの再構築で発生した問題まとめでネットワークカード絡みの問題を抱えているため、M/Bであると推測するのが妥当
しかしながらM/Bを検証するためのリソースが存在していないため、この時点では打つ手無し

6. 本当に電源が入らない

前述した一時的にファンが回転する、というような通電を観測できるような現象ではなく、何の反応もなくなる

・本当にM/Bが壊れた
推測ではなく確定
しかしCPUが原因という可能性も完全には否定できないが、CPUを交換しての再検証などは行っていない


短期間で様々な問題が発生したこと、使用期間が7年前後であること、そもそも起動しないことなどからリプレースすることに決定
G3220のコストパフォーマンスが非常に良いことは以前から判明しているので……

旧構成
CPU: AMD Athlon X2 BE-2350
M/B: ASUS M2A-VM
PCIex16: Broadcom NetXtreme BCM5751
PCI: Intel GT DP 82546GB -> Broadcom NetXtreme BCM5703
PCI: Intel GT DP 82546GB -> Broadcom NetXtreme BCM5703
PCIex1: Broadcom NetXtreme BCM5751
PS: DPS-300AB-9C
Case: CS-01B-B/300V2

新構成
CPU: Intel Pentium Processor G3220
M/B: ASUS H81M-PLUS
PCIex16: Intel CT 82574L
PCIex1: Intel CT 82574L
PCIex1: Intel CT 82574L
PCIex1: Intel CT 82574L
PS: DPS-300AB-9C
Case: CS-01B-B/300V2

と、このように変更
電源は検証の結果、特に問題がないようなので流用することにした

また実はIntel CT 82574Lの前にBroadcom NetXtreme BCM5751を4枚挿して動かそうと試みているのだが、実は失敗している
これについての検証は検証といえるほど行っていないのだが、複数枚挿すとファンが回った直後にストールするため、全てIntel製で統一する必要があった背景がある

1枚だと何の問題もなく、但しIntel CT 82574Lを3枚にBroadcom NetXtreme BCM5751というような構成の場合、OSがBroadcomのカードのみ認識できない
またBIOSのいくつかの設定を変更することで2枚までは問題が再現しなくなるが、3枚目を無事に動かすことはできていない
但しSATAを無効にしたりと通常仕様に耐えない項目まで変更しているので、詳細については割愛する

旧構成から新構成に至るまで発生した問題は何1つとして原因が判明していないので、正直価値のない内容になるが、個人的に現象の記録として必要なので書き起こした
add comment ( 1414 views )
Sunday, March 23, 2014, 01:44 - Misc
Posted by ELIN
802.11b
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 49763 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.2 sec 19.5 MBytes 5.42 Mbits/sec

802.11g
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 49846 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.1 sec 79.8 MBytes 22.2 Mbits/sec

802.11ng 20MHz
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 49932 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 270 MBytes 75.3 Mbits/sec

802.11ng 40MHz
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 52416 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 329 MBytes 92.0 Mbits/sec

802.11a
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 52564 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.1 sec 81.6 MBytes 22.8 Mbits/sec

802.11na 20MHz
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 52738 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.1 sec 222 MBytes 61.9 Mbits/sec

802.11na 40MHz
------------------------------------------------------------
Client connecting to 192.168.100.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.100.3 port 52857 connected with 192.168.100.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 375 MBytes 105 Mbits/sec
add comment ( 3019 views )
Saturday, March 22, 2014, 04:18 - Hardware
Posted by ELIN
大昔に買ってそのまま何にも使用していなかったMicrosoftのLifeCam VX-1000というWebcamがあるのだが、思うところがあり動かしてみることにした

しかしこれはキワモノでも何でもない至って普通のデバイスなので、Windowsなマシンに挿そうものなら勝手にドライバをインストールし、何もしないまま普通に動いてしまう
当然このようなことは誰も望んでいないので、OpenWrtのWZR-HP-AG300Hに挿すことにする

さて、最初は正しいドライバを探すところから始まる
OpenWrtのリポジトリにはkmod-video-gspca-*なものが揃ってはいるが、PCIないしPCIeスロットに挿すような見ればわかるデバイスと異なり、USBデバイスは見ただけではドライバを判別するのが困難なのでこれを調べる必要がある
http://cateee.net/lkddb/web-lkddb/USB_GSPCA.htmlによると、VX-1000はkmod-video-gspca-sonixjであるらしいのでこれをインストール

次に動作確認としてOpenWrt上でWebcamからデータを取り出してみる
これはmjpg-streamerをインストールし
# mjpg_streamer -i "input_uvc.so -f 10 -d /dev/video0 -n" -o "output_http.so -w /www/webcam"
こう

ちなみに動かない場合は適当にパラメータを弄ると動いたりする
パラメータの詳細はここ

これでhttp://192.168.1.1とするとWebcamの映像を確認することができる

さて、対して苦労もせず動いてしまったので、次はUSB over IPを試してみる
これはどういうことかと言うと、WZR-HP-AG300Hに接続されたVX-1000をVM上のWindows XPから制御してみようというわけ

まずOpenWrtでusbip-serverをインストールし
# usbip list -l
Local USB devices
=================
- busid 2-1 (045e:00f7)
2-1:1.0 -> sonixj
2-1:1.1 -> unknown
2-1:1.2 -> unknown

# usbip bind -b 2-1
bind device on busid 2-1: complete
# usbipd -D

もしサーバサイドのログが必要なら
# usbipd -d

Windows側ではhttp://usbip.sourceforge.net/からusbip_windows_v0.2.0.0_signed.zipを入手する
そしてコントロールパネルのハードウェアの追加から落としてきたドライバを指定してデバイスを作成する

>usbip -l 192.168.1.1
とするとbindしたデバイスが見えるはずなのだが
- 192.168.1.1
usbip err: usbip_network.c: 121 (usbip_recv_op_common) recv op_common, -1
usbip err: usbip.c: 216 (query_exported_devices) recv op_common
usbip err: usbip.c: 288 (show_exported_devices) query

このような感じで見えない

サーバサイドでは
usbip: debug: usbip_network.c:149:[usbip_net_recv_op_common] version mismatch: 262 273
usbipd: debug: usbipd.c:230:[recv_pdu] could not receive opcode: 0

と出力され、バージョン不一致であることがわかる

usbip.exeのバイナリを書き換えてバージョンを誤魔化してみたりもしたが、パケットに載せるコマンド番号そのものが異なっているらしく動作しなかった
誰かわかってるやつがなんとかしてくれてないかなー、と探してみるとhttp://www.raspberrypi.org/forum/viewtopic.php?f=28&t=8858&start=25にそれっぽいバイナリを発見

結果
>usbip -l 192.168.1.1
usbip for windows ($Id$)

- 192.168.1.1
2-1: unknown vendor : unknown product (045e:00f7)
: /sys/devices/platform/ohci-platform/usb2/2-1
: (Defined at Interface level) (00/00/00)
: 0 - unknown class / unknown subclass / unknown protocol (ff/ff/ff)
: 1 - unknown class / unknown subclass / unknown protocol (01/01/00)
: 2 - unknown class / unknown subclass / unknown protocol (01/02/00)

と、出力を得る

そして接続
>usbip -a 192.168.1.1 2-1
これでデバイスマネージャにもVX-1000が見えて接続されていることがわかる

しかし何らかのデータは飛んできてはいるものの、Webcamの動作までは至っていない
真っ黒だったり、バグったjpegのようだったり、映像を正常に受け取ることができない状態だ

usbipではない別のプロダクトとしてhttps://www.virtualhere.com/もあるが、同じように動作しない
ただMicrosoft純正のアプリケーションでのみ正常に映った

恐らくだがWebcamが若干悪い気がしないでもないので、別のWebcamを入手したときに試してみることにする
ちなみにマウスなどは普通に動いてる
add comment ( 4848 views )

| 1 | 2 | 3 | Next> Last>>