付録基板のhttpサーバをダウングレードしてみた [ColdFire V2]
SilentCにパッチをあてて、httpサーバをダウングレードしてみました。 これも、"masato"さんの尊い人柱レポートのおかげです。
httpサーバのダウングレード
この作業は、SilentCにパッチをあてることになるので、付録基板がEzPORTによるリカバリを必要とするぐらいのダメージを受ける可能性があります。 このため、今まで使ってきた「青号」ではなく「橙号」を出してきました。 皆さんが追試されるときにも十分に注意してください。
ダウン・グレードといっても、大したことはしていません。 httpサーバが返してくる"HTTP/1.1 200 OK"の文字列を"HTTP/1.0 200 OK"に変更するだけです。 この文字列は、以下の場所にあります。
000116b8 74 73 3f 00 46 75 6c 6c ts?.Full 000116c0 3f 00 48 54 54 50 2f 31 ?.HTTP/1 000116c8 2e 31 20 32 30 30 20 4f .1 200 O 000116d0 4b 0d 0a 43 6f 6e 74 65 K..Conte
これを書き換えるためにドキュメントには書かれていない"NvmWrite"という関数を使います。 使用したプログラムは、以下のとおりです。
main(){
long *patch=MemoryAlloc(16);
long *target=0x116c8;
do {
BufCopy(patch,target,4);
if (*patch!=0x2e312032) {
PrStr("Invalid Program\r\n");
break;
}
*patch=0x2e302032;
NvmWrite(target+0xFFF00000, patch, 4);
} while(0);
MemoryFree(patch);
}
"NvmWrite"という関数は、FLASHへの書き込みを行うプログラムをRAMに展開して、実行します。 この間、FLASHは、アクセス不能になります。 そのため、書き込みに必要な情報は、すべてRAMに配置しておく必要があります。 このプログラムでも該当アドレスの内容を"MemoryAlloc"関数で確保したヒープ領域に配置して、書き込むべきデータのバッファとして使用しています。
プログラムを実行した結果が、これです。
000116b8 74 73 3f 00 46 75 6c 6c ts?.Full 000116c0 3f 00 48 54 54 50 2f 31 ?.HTTP/1 000116c8 2e 30 20 32 30 30 20 4f .0 200 O 000116d0 4b 0d 0a 43 6f 6e 74 65 K..Conte
この方法で、自由自在にパッチが当てられそうなのですが、適用範囲は限定されています。 今回は、0x31というデータを0x30というデータに書き換える「あるビットを1から0に変更するパッチ」だったので、簡単に出来ました。 もち、逆に「0から1に変更する」のだったら、FLASHを一旦消去して、書き換える必要があるので、こんなに簡単にはいきません。
また、このパッチは、該当箇所を余分にプログラムしてしまうことになるので、深く書き込みすぎてしまう可能性があります。 これは、「deep program」と呼ばれる状態で、セルが劣化したり、消去できなくなったりする可能性があります。 このFLASHモジュールの書き込みアルゴリズムがどうなっているのか、明確ではありませんが、あくまでも「消去してから書き込み」というのが正式な手順です。
パケット・モニタで確認
パッチをあてたところで、パケット・モニタで通信状態を確認してみます。
#1 0.000000 192.168.1.2 192.168.1.103 TCP 1517 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460 #2 0.000394 192.168.1.103 192.168.1.2 TCP 80 > 1517 [SYN, ACK] Seq=0 Ack=1 Win=1454 Len=0 #3 0.000484 192.168.1.2 192.168.1.103 TCP 1517 > 80 [ACK] Seq=1 Ack=1 Win=16616 Len=0
おなじみ３ウェイ・ハンドシェイクです。
#4 0.008741 192.168.1.2 192.168.1.103 HTTP GET /RiverSeaTemplate.htm HTTP/1.1 TCP 1517 > 80 [PSH, ACK] Seq=1 Ack=1 Win=16616 Len=430 #5 0.009719 192.168.1.103 192.168.1.2 TCP 80 > 1517 [ACK] Seq=1 Ack=431 Win=1454 Len=0 #6 0.013506 192.168.1.103 192.168.1.2 HTTP HTTP/1.0 200 OK (text/html) TCP 80 > 1517 [PSH, ACK] Seq=1 Ack=431 Win=1454 Len=1377
最初は、HTML文書の要求から。 ColdFireからの返答が"HTTP/1.0 200 OK"になっているのが確認できます。
#7 0.054387 192.168.1.2 192.168.1.103 HTTP GET /W.gif HTTP/1.1 TCP 1517 > 80 [PSH, ACK] Seq=431 Ack=1378 Win=16616 Len=437 #8 0.055376 192.168.1.103 192.168.1.2 TCP 80 > 1517 [ACK] Seq=1378 Ack=868 Win=1454 Len=0 #9 0.055416 192.168.1.103 192.168.1.2 TCP 80 > 1517 [FIN, ACK] Seq=1378 Ack=868 Win=1454 Len=0 #10 0.055472 192.168.1.2 192.168.1.103 TCP 1517 > 80 [ACK] Seq=868 Ack=1379 Win=16616 Len=0 #11 0.056353 192.168.1.2 192.168.1.103 TCP 1517 > 80 [FIN, ACK] Seq=868 Ack=1379 Win=16616 Len=0 #12 0.056673 192.168.1.103 192.168.1.2 TCP 80 > 1517 [ACK] Seq=1379 Ack=869 Win=1454 Len=0
ところが、ブラウザは、同じポートを使い#7でGIFファイル W.gif を要求してきます。 ColdFireは、#7に対する応答として#8を返しますが、同時に#9でコネクションの終了を宣言します。 この部分は、HTTP/1.1だった時と同じです。 ブラウザが、HTTP/1.0を認識していないのか？
#13 0.057777 192.168.1.2 192.168.1.103 TCP 1520 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460 #14 0.058129 192.168.1.103 192.168.1.2 TCP 80 > 1520 [SYN, ACK] Seq=0 Ack=1 Win=1454 Len=0 #15 0.058201 192.168.1.2 192.168.1.103 TCP 1520 > 80 [ACK] Seq=1 Ack=1 Win=16616 Len=0 #16 0.059826 192.168.1.2 192.168.1.103 HTTP GET /B.gif HTTP/1.1 TCP 1520 > 80 [PSH, ACK] Seq=1 Ack=1 Win=16616 Len=437 #17 0.060798 192.168.1.103 192.168.1.2 TCP 80 > 1520 [ACK] Seq=1 Ack=438 Win=1454 Len=0 #18 0.062053 192.168.1.103 192.168.1.2 HTTP HTTP/1.0 200 OK (GIF89a) TCP 80 > 1520 [PSH, ACK] Seq=1 Ack=438 Win=1454 Len=415
続いて、二回目のコネクションでブラウザが GIFファイル B.gif を要求します。 HTTP/1.1の時には、ここで、GIFファイルを要求するコネクションが二つ同時に飛んできたのですが、今回はひとつだけです。 GIFファイルを受信し終えて、コネクションの終了かと思っていたら、
#19 0.067185 192.168.1.2 192.168.1.103 TCP 1521 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460 #20 0.067542 192.168.1.103 192.168.1.2 TCP 80 > 1521 [SYN, ACK] Seq=0 Ack=1 Win=1454 Len=0 #21 0.067606 192.168.1.2 192.168.1.103 TCP 1521 > 80 [ACK] Seq=1 Ack=1 Win=16616 Len=0 #22 0.075055 192.168.1.2 192.168.1.103 HTTP GET /W.gif HTTP/1.1 TCP 1521 > 80 [PSH, ACK] Seq=1 Ack=1 Win=16616 Len=437 #23 0.076056 192.168.1.103 192.168.1.2 TCP 80 > 1521 [ACK] Seq=1 Ack=438 Win=1454 Len=0 #24 0.077340 192.168.1.103 192.168.1.2 HTTP HTTP/1.0 200 OK (GIF89a) TCP 80 > 1521 [PSH, ACK] Seq=1 Ack=438 Win=1454 Len=425
コネクションを終了させる前に二つ目のGIFファイル W.gif の要求が始まってしまいました。 GIFファイルを受け取って、今度は本当に通信終了だよね。
#25 0.168419 192.168.1.2 192.168.1.103 TCP 1520 > 80 [ACK] Seq=438 Ack=416 Win=16201 Len=0 #26 0.168786 192.168.1.103 192.168.1.2 TCP 80 > 1520 [FIN, ACK] Seq=416 Ack=438 Win=1454 Len=0 #27 0.168861 192.168.1.2 192.168.1.103 TCP 1520 > 80 [ACK] Seq=438 Ack=417 Win=16201 Len=0
次のパケットは、ブラウザから送信されます。 これは、#18に対する返答で、返答までに要した時間は、約0.1秒でした。 ColdFireは、#26でコネクション終了を宣言し、#27でブラウザが受信確認を送ります。
#28 0.269074 192.168.1.2 192.168.1.103 TCP 1521 > 80 [ACK] Seq=438 Ack=426 Win=16191 Len=0 #29 0.269476 192.168.1.103 192.168.1.2 TCP 80 > 1521 [FIN, ACK] Seq=426 Ack=438 Win=1454 Len=0 #30 0.269553 192.168.1.2 192.168.1.103 TCP 1521 > 80 [ACK] Seq=438 Ack=427 Win=16191 Len=0
続いて、#24に対する返答が#28で返されます。 返答までの所要時間は、0.2秒です。 ColdFireは、#29でコネクション終了を宣言し、ブラウザが#30で受信確認します。
#31 5.933938 192.168.1.2 192.168.1.103 TCP 1520 > 80 [FIN, ACK] Seq=438 Ack=417 Win=16201 Len=0 #32 5.934275 192.168.1.103 192.168.1.2 TCP 80 > 1520 [ACK] Seq=417 Ack=439 Win=1454 Len=0 #33 5.934329 192.168.1.2 192.168.1.103 TCP 1521 > 80 [FIN, ACK] Seq=438 Ack=427 Win=16191 Len=0 #34 5.934683 192.168.1.103 192.168.1.2 TCP 80 > 1521 [ACK] Seq=427 Ack=439 Win=1454 Len=0
ここから、前の実行結果と多少異なっています。 ブラウザが"FIN"を送信するのは、5.5秒後です。 前回は、8秒かかっていました。 また、ColdFireも今回は、"FIN"に対して"ACK"を確実に返しています。 そのため、パケットの送受信は、ここで終了します。
本日の考察
- httpサーバをHTTP1.0にダウン・グレードすると、ブラウザは同時に複数の通信を要求する振る舞いはしない。
- ただし、データ転送が終了した後でもコネクションは張られたままなので、複数コネクションを行っているようにも見える。
- ブラウザが"FIN"を発行するタイミングが早いので、ColdFireは、"ACK"で応える事が出来る。
GIFファイルの数をもっと増やしたらどうなるんでしょうね。
参考文献
![Interface (インターフェース) 2008年 09月号 [雑誌]](https://images-fe.ssl-images-amazon.com/images/I/51VLUjLBhxL._SL160_.jpg "Interface (インターフェース) 2008年 09月号 [雑誌]")
Interface (インターフェース) 2008年 09月号 [雑誌]
- 作者:
- 出版社/メーカー: CQ出版
- 発売日: 2008/07/25
- メディア: 雑誌
2008-10-01 15:59
nice!(0)
コメント(2)
トラックバック(0)
コネクションの切断を待たずに送って来ましたか。
うーん、判らん。
ブラウザを変えてやったらどうなるのかなぁ。OperaとかIEとかクロームとか(笑)。
by hamayan (2008-10-01 17:59)
IEで試してみましたが、若干早いだけで、Firefoxの時と同じやりとりでした。
ｈｔｔｐプロトコルのレイヤーは、共通なのかな？
by noritan (2008-10-01 22:56)