ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！
ＶＨＤＬを速習！　ＸＣ９５１４４ＸＬ＋１６ＭＢ・ＳＩＭＭを使ってＵＳＢプロトコルアナライザを作ってしまいました！
主目的は差し迫った事情からＵＳＢプロトコルの解析をすることだったのですが、その手段として選んだのがコレ！


［第２７回］


●ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲ（２）

前々回（［第２５回］）からの続きです。
ＳＴＲＩＮＧ　ＤＥＡＳＣＲＩＰＴＯＲの送受信の記録を見ていただいて、そこにおかしなところがあるのですがそれがどこだかわかりますでしょうか、というところで終わりました。
もう一度そのリストをお見せします。

(D6PX6CK.TXT) 0025900 SOF FNO=73D 0025910 SETUP ADRS=04 ENDP=00 DATA0 80 06 03 03 09 04 FF 00 GET_DESCRIPTOR ACK 0025912 IN ADRS=04 ENDP=00 NAK 0025913 IN ADRS=04 ENDP=00 NAK 0025914 IN ADRS=04 ENDP=00 NAK 0025916 IN ADRS=04 ENDP=00 DATA1 10 03 4F 00 6C 00 48 00 ACK 0025918 IN ADRS=04 ENDP=00 NAK 0025918 IN ADRS=04 ENDP=00 NAK 0025919 IN ADRS=04 ENDP=00 NAK 0025920 IN ADRS=04 ENDP=00 NAK 0025922 IN ADRS=04 ENDP=00 DATA0 6F 00 73 00 73 00 00 00 ACK 0025922 IN ADRS=04 ENDP=00 NAK 0025924 IN ADRS=04 ENDP=00 DATA1 ACK 0025926 OUT ADRS=04 ENDP=00 DATA1 ACK 0025960 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 02 00 00 FF 00 GET_DESCRIPTOR CONFIG ACK

このリストでは、ホストから送出されたＧＥＴ　ＤＥＳＣＲＩＰＴＯＲコマンドと、それに応えてＰＩＣＷＲＩＴＥＲからＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲが送出されたところが記録されています。
ホストからの送信要求に応えてＰＩＣＷＲＩＴＥＲが送信した最初の８バイトのデータは
１０　０３　４Ｆ　００　６Ｃ　００　４８　００　
でした。
先頭の１バイトはこのディスクリプタの長さを示しています。
１０Ｈですからこのディスクリプタ（シリアルナンバー）は全体で１６バイトであることを示しています。

ホストからは何回もＩＮパケットが送られていますが、準備ができていないときはＮＡＫを返しています。
まともに応答したのは２回ですから、８バイト×２＝１６バイトのデータを送っています。
ＰＩＣＷＲＩＴＥＲはこれで必要なデータ１６バイトを送りましたし、その長さが１６バイトであることはデータの先頭に１０Ｈを置いたことでホストも当然わかっているはずです。

ところが１６バイトを送り終わったにもかかわらず、ホストからはさらにＩＮパケットが送出されています。
おかしいと書いたのはそこのところなのです。
２５９２２行で最後の８バイトを送出したにもかかわらず、その直後にまたＩＮパケットが出されています。
このときはＰＩＣＷＲＩＴＥＲはまだ応答の準備ができていないらしくＮＡＫを返しています。
次の２５９２４行のＩＮパケットではもう何も送るデータがありませんから、データなし（０バイト）のＤＡＴＡ１だけを返しています。
そこでやっとホストからは全てのデータを受け取ったしるしとしてデータなしのＤＡＴＡ１が送出されて、これでやっとＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲの１つのやり取りが終了しました。

しかし、ここで記録されたやり取りは、上で説明しましたようにどう考えても納得がいきません。
このやり取りからはＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲの先頭に置いたデータ長の１バイトが全く無視されてしまっています。
こんなことになっているとは全く考えてもいませんでしたから、私のＰＩＣプログラムでＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲを送るようにしたときには、最初はほかのＤＥＳＣＲＩＰＴＯＲと同様に必要なバイト数だけを送ってそれでおしまい、という風に書いたところ、それが原因で「不明なデバイス」にされてしまいました。
そこで、おかしいと思って繰り返し記録をとって調べたところ、上記のことが明らかになったのでした。

このことが明らかになった当初は、これがＵＳＢ３．０固有の振る舞いであると思いました。
しかし念のためにほかのＷｉｎｄｏｗｓパソコン（ＵＳＢ２．０）で調べてみたところ、ＵＳＢ２．０でも全く同じであることがわかりました。

下はＷｉｎｄｏｗｓ９８ＳＥ（ＵＳＢ２．０）にＰＩＣＷＲＩＴＥＲを接続したときの記録データを解析したもので、上のリストと同じ部分のリストです。

(D6P9_2CK.TXT) 0325092 SOF FNO=26A 0325093 SETUP ADRS=02 ENDP=00 DATA0 80 06 03 03 09 04 FF 00 GET_DESCRIPTOR ACK 0325187 SOF FNO=26B IN ADRS=02 ENDP=00 DATA1 10 03 4F 00 6C 00 48 00 ACK 0325279 SOF FNO=26C 0325281 IN ADRS=02 ENDP=00 DATA0 6F 00 73 00 73 00 00 00 ACK 0325373 SOF FNO=26D 0325374 IN ADRS=02 ENDP=00 DATA1 ACK 0325467 SOF FNO=26E 0325561 SOF FNO=26F 0325562 OUT ADRS=02 ENDP=00 DATA1 0325655 SOF FNO=270 0325748 SOF FNO=271 0325750 SETUP ADRS=02 ENDP=00 DATA0 80 06 00 02 00 00 FF 00 GET_DESCRIPTOR CONFIG ACK

見ていただければわかりますように、さきほどのリストと全く同じです。
これはＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲだけに見られることのようで、他のＤＥＳＣＲＩＰＴＯＲの送受ではこのようなおかしなことはおきていないようです。
そしてそれはＵＳＢ３．０だけではなくてＵＳＢ２．０でも同じであることから、何らかの理由でＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲについてはこういうルールになっているものと思われます。

ところでこのリストではコマンドやデータの送信や受信がＳＯＦで始まる１つのフレームに１回というように、ゆっくりとしたやり取りで行なわれていることがおわかりいただけると思います。
さきほどのリスト（ＵＳＢ３．０）ではＩＮパケットが１０〜２０μｓ毎という非常に短い時間で出されているのですが、このリスト（ＵＳＢ２．０）ではフレーム毎（１フレームは１ｍｓ）というゆっくりとした間隔で出されています。

［第２１回］に書きましたように、私はそういうものだと理解してＰＩＣプログラムを書きましたので、ＵＳＢ３．０の猛烈な速度には応答できなくて結果として「不明なデバイス」にされてしまったのでした。
勿論今はＵＳＢ３．０の速度にも応えられるようにＰＩＣプログラムを修正しましたので、それでやっと「不明なデバイス」問題はクリアできました。

ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！［第２７回］
２０１４．３．１２ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る