Messenger on VirtualBox

Live MessengerなどのメッセンジャーをVirtualBox上で動作させると、
メッセージが送信できないことがある。
状況としては、メッセージを送っても、送信されておらず相手に表示されない。
ただ、逆に相手からのメッセージの受信はできて、すぐに返事を返せば相手に送信される。
しかし、すぐに返事を返さなくて間があくと、メッセージが送られない。

Wiresharkで様子を見ながら再現をすると以下のようになる。

VirtualBoxのゲスト内で実行しているメッセンジャーをA、ホスト上で実行しているのをBとする。
接続の構成は、以下の通りとなっている。

VirtualBoxゲスト(10.0.2.15) <--(NATで接続)--> VirtualBoxホスト(192.168.0.5) <--(LAN)-->
ルータ(192.168.0.1) <--> インターネット

ゲストのOSは、Windows XP Professional SP3を使用し、ホストのOSは、Debian Linux Lennyを使用した。
VirtualBoxのバージョンは2.1.4で、ゲスト側ではGuest Additionsを実行している。
また、Wiresharkはゲスト側、ホスト側の両方で実行し、ログを取得している。

再現の手順は以下のとおりである。

1,BからAへメッセージを送信する。このときは特に問題が起きない。

2,すぐに、AからBへ返事を返す。このときも問題はない。

3,5分位待つ。

4,再び、AからBへ返事を返す。しかし、メッセージは送られない。

このとき、Wiresharkで様子を観察すると以下のようになる。

・ゲスト側
メッセージは正常に送信されていることになっていて、ACKが返ってきている。

No Time SrcAddr DstAddr Protocol Info
1397 652.706620 10.0.2.15 207.46.26.43 MSNMS MSG 134 U 99
1398 652.708407 207.46.26.43 10.0.2.15 TCP msnp > ansoft-lm-2 [ACK] Seq=436 Ack=725 Win=8760 Len=0
1399 653.574110 10.0.2.15 207.46.26.43 MSNMS MSG 135 N 127
1400 653.575529 207.46.26.43 10.0.2.15 TCP msnp > ansoft-lm-2 [ACK] Seq=436 Ack=867 Win=8760 Len=0

・ホスト側
メッセージは正常に送信されておらず、TCPによって再送信されている。

No Time SrcAddr DstAddr Protocol Info
5996 656.703663 192.168.0.5 207.46.26.43 MSNMS MSG 134 U 99
5997 657.452573 192.168.0.5 207.46.26.43 MSNMS [TCP Retransmission] MSG 134 U 99
5998 658.956576 192.168.0.5 207.46.26.43 MSNMS [TCP Retransmission] MSG 134 U 99

(注意:フレーム番号と時間がずれているが、ゲストとホストで実行しているタイミングが異なるため)

想定している挙動としては、ゲスト側でACKが返ってきているのであれば、ホスト側でもACKが返ってきているはずである。
しかし、実際にはホスト側でACKが表れることはなく、ゲスト側では送信されているはずの「MSNMS MSG 135 N 127」がホスト側で送信されていない。
よって、ゲストからホストの間のネットワーク通信の間で問題が起きていることが考えられる。

原因としては、以下のようなことを考えているが、現在調査中。。。

1つには、VirtualBoxのネットワークドライバがわざとACKのメッセージを送信していることが考えられる。
もう1つには、理由がまだ分かっていないが、何かしらの理由でTCPの再送が発生してしまっている。
また、このときのネットワークドライバの挙動が怪しい。

前者については、妥当な理由が思いついているので、あとはソースコード上から証拠を探すだけ。
後者は、いろいろと調べる必要がありそう。。。正直、はっきりとしない。

とりあえず、VirtualBoxのソースコードをダウンロードしてきて調べるか・・・。

Posted at : 2009-03-28 22:24:37 / Category : none

Comments

VirtualBox の NAT って slirp みたいなものを使ってるんじゃないですか? qemu の -net user がそうですが、ホストの TCP/IP スタックをつかって送受信するので、一般ユーザの権限でもパケットが投げられるかわりに、ping がとばないとか、再送はホストの TCP スタックが行うとか、ちょっとした違いがあります。なので、たとえば、なんらかの理由で TCP セッションが切れてしまったとき (ルーターの NAPT のタイムアウト等) はそのような挙動になるのは正常です。

hdk - 2009-03-31 01:26:36

お久しぶりです。

あぁ、なるほど。それはあるかもしれないです。。。
pingはとんでますが、確かに、再送はホスト側で処理をやってますね。

情報をありがとうございます。とりあえず、ソースを眺めながら調べてみます。

yasuharu - 2009-04-01 23:38:25

Send comment


Name


Mail-address (empty is OK. If you want to notify update, please fill mail-address.)


Bot check code (240419 と入力してください / Please input 240419.)