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


［第６４回］


●Ｅｎｕｍｅｒａｔｉｏｎ　はじめから終わりまでの記録（１７）４度目のＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）

前回からの続きです。
前回はなんと４回目のＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＳＴＲＩＮＧ）の出現に、もう言葉もありません、と書きました。
一体どうなっているのでしょうか。
全くの謎なのでありますが、ともかく私といたしましては、こんなわけのわからないふるまいのもとになりますＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲなぞ金輪際使う気はありません。
ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲは記述しなくてもよいことになっているようですし、実用上も記述する必要は全くありません。

さて。前回のリストの続きです。

0252903 SOF FNO=0B3 0252977 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 01 00 00 12 00 GET_DESCRIPTOR DEVICE ACK 0252978 IN ADRS=04 ENDP=00 NAK 0252980 IN ADRS=04 ENDP=00 NAK 0252980 IN ADRS=04 ENDP=00 0252982 IN ADRS=04 ENDP=00 DATA1 12 01 00 02 00 00 00 08 ACK 0252984 IN ADRS=04 ENDP=00 NAK 0252985 IN ADRS=04 ENDP=00 NAK 0252986 IN ADRS=04 ENDP=00 DATA0 D8 04 33 00 02 00 01 02 ACK 0252987 IN ADRS=04 ENDP=00 0252988 IN ADRS=04 ENDP=00 0252989 ACK 0252990 OUT ADRS=04 ENDP=00 DATA1 ACK 0252997 SOF FNO=0B2 0252997 PRE 0253013 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 02 00 00 09 00 GET_DESCRIPTOR CONFIG ACK 0253015 IN ADRS=04 ENDP=00 NAK 0253016 IN ADRS=04 ENDP=00 NAK 0253017 IN ADRS=04 ENDP=00 NAK 0253018 IN ADRS=04 ENDP=00 NAK 0253020 IN ADRS=04 ENDP=00 DATA1 09 02 29 00 01 01 02 80 ACK 0253021 NAK 0253022 IN ADRS=04 ENDP=00 DATA0 32 C1 6A 3B A0 F4 1E 0253023 OUT ADRS=04 ENDP=00 DATA1 ACK 0253045 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 02 00 00 29 00 GET_DESCRIPTOR CONFIG ACK 0253046 IN ADRS=04 ENDP=00 NAK 0253047 IN ADRS=04 ENDP=00 NAK 0253048 IN ADRS=04 ENDP=00 NAK 0253050 IN ADRS=04 ENDP=00 DATA1 09 02 29 00 01 01 02 80 ACK 0253051 IN ADRS=04 ENDP=00 NAK 0253053 IN ADRS=04 ENDP=00 NAK 0253054 IN ADRS=04 ENDP=00 NAK 0253056 IN ADRS=04 ENDP=00 DATA0 32 09 04 00 00 02 03 00 0253057 ACK 0253057 IN ADRS=04 ENDP=00 NAK 0253059 IN ADRS=04 ENDP=00 NAK 0253060 IN ADRS=04 ENDP=00 NAK 0253061 IN ADRS=04 ENDP=00 DATA1 ? [00000001] ? [10000110] 0253062 IN ADRS=04 ENDP=00 NAK 0253064 IN ADRS=04 ENDP=00 NAK 0253065 IN ADRS=04 ENDP=00 NAK 0253067 IN ADRS=04 ENDP=00 DATA0 22 1D 00 07 05 81 03 40 ACK 0253068 IN ADRS=04 ENDP=00 NAK 0253069 IN ADRS=04 ENDP=00 NAK 0253070 IN ADRS=04 ENDP=00 NAK 0253072 IN ADRS=04 ENDP=00 DATA1 00 01 07 05 01 03 40 00 ACK 0253074 IN ADRS=04 ENDP=00 NAK 0253075 IN ADRS=04 ENDP=00 DATA0 01 81 7F 3A A0 F4 7E 00 0253077 OUT ADRS=04 ENDP=00 DATA1 ACK

やっとＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲから抜け出せたようです。
おやおや。
今度はＤＥＶＩＣＥ　ＤＥＳＣＲＩＰＴＯＲの要求です。
ＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＤＥＶＩＣＥ）は［第３８回］で説明しました。
ＵＳＢ接続を開始したとき最初にホストから出されるのが、このＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＤＥＶＩＣＥ）で、その後アドレスが与えられて再びＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＤＥＶＩＣＥ）が出されます。
そのときその要求に応えてしっかりＤＥＶＩＣＥ　ＤＥＳＣＲＩＰＴＯＲを送りましたのに、ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲと同じく、またもや同じＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＤＥＶＩＣＥ）です。

うむむ。
ＵＳＢのＥＮＵＭＥＲＡＴＩＯＮというのはちょっとしつこいといいますか、何かおかしいのと違いますかあ。
ぼやいてみたってはじまりません。
要求されたら何回でもそれに応えるしかありません。
で、応えますと。
今度はＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）です。
ＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）は［第４０回］で説明しました。
そのときと全く同じことの繰り返しです。

あ。
いえ。
全く同じではないようです。
［第４０回］ではＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）で９バイトのみの要求に対して先頭の９バイトを送ると、次はＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲの要求が出されました（［第４３回］）。

しかし今回は続いてまた同じＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）が出されています。
よく見ますと先のＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）では９バイトの要求だったのですが、今度は４１バイト（２９Ｈ）の要求です。
これは先のＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）に応えて送った
09 02 29 00 01 01 02 80
の３バイト、４バイト目でＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの全体の長さか００２９Ｈ（４１バイト）だと記述したことに対して出された要求のようです。

それに応えてＰＩＣＷＲＩＴＥＲからは、今度はＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの全部が送出されています。
全データは４１バイトですから８ビットを６回送出しなければならないはずですが、リストでは５回しか見えません。
どうやら中ほどに少し乱れが見えますからそこに１回のデータがあって、それが自作アナライザではうまくキャッチできなかったようです。
ま。しかし。
そのあたりはそういうことにしておきましょう。
余り繰り返し同じ要求が出されるものですから、いささか疲れてしまいました。
次にいきましょう。

［１４．６．１１追記］
昨晩はこの記事を書きながら、「はて、ＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）は、まだほかにも出されていたのじゃなかったかなあ？」とちょいと疑問を感じたのですが、もう眠かったのでよく確認しないで書いてしまいました。
やっぱりしっかりウラをとらないで書いたりしますと間違ったことを書いてしまいます。
ＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）は上に書きました２回目の９バイトの要求の後、一旦はＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲの要求が出されたあと、今度はバイト数を指定しないで３回目が出されておりました（［第４５回］、［第４６回］）。
つうことは、このときＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの全てを送っておりますから、もうそれで完了していてもよさそうなものだと思います。
それなのにまたもや同じ要求が重ねて出されていることになります。
むむ。
ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲだけではなくて、ここでもしつこいことをやっているのですねえ。
ま。
少しずつは進んでいるようでありまして、この前の要求ではバイト数を指定しないでＦＦＨとしての要求だったのですが（トータルが４１バイトだということはその前のときに送っていますから、本当はもうそこで２９Ｈを指定してもよさそうなものだと思いますけれど）、今回はやっとバイト数を４１バイト（２９Ｈ）と指定して要求が出されています。
いやあ。
ＥＮＵＭＥＲＡＴＩＯＮは本当にしつこい！

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

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