From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K6U17-0006P0-BS for qemu-devel@nongnu.org; Wed, 11 Jun 2008 13:21:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K6U15-0006Ok-Rm for qemu-devel@nongnu.org; Wed, 11 Jun 2008 13:21:48 -0400 Received: from [199.232.76.173] (port=37377 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6U15-0006Of-Hw for qemu-devel@nongnu.org; Wed, 11 Jun 2008 13:21:47 -0400 Received: from mail.windriver.com ([147.11.1.11]:57225 helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K6U15-0001W5-Dg for qemu-devel@nongnu.org; Wed, 11 Jun 2008 13:21:47 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m5BHLglj003718 for ; Wed, 11 Jun 2008 10:21:42 -0700 (PDT) Message-ID: <485009A9.6000900@windriver.com> Date: Wed, 11 Jun 2008 12:21:45 -0500 From: Jason Wessel MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020401040602040504050408" Subject: [Qemu-devel] [PATCH] Proposed fix broken RST response to a slirp redirect socket Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------020401040602040504050408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit When using slirp networking with a redirected tcp socket, the qemu guest os does not receive RST packets when a redirected, accepted socket goes into the FIN_WAIT_2 status. Presently slirp sends ACKs instead of RST packets, which means the guest os application socket writes do not fail event after the client has terminated the socket. Here is a simple way to demonstrate the problem. * Start qemu with user mode networking plus: -redir tcp:4441::4441 * Assuming you booted a linux guest os you could run: cat /dev/zero | nc -p 4441 -l * On the host run the following command and you must hit control-c after about 1 second nc localhost 4441 If you were to TCP dump the connection in the guest OS you would see after killing the "nc" on the host computer that slirp keep acking the packets, even though no client application is there. 14:55:38.385310 IP 10.0.2.15.4441 > 10.0.2.2.37227: P 8884509:8885077(568) ack 2 win 5840 14:55:38.385310 IP 10.0.2.2.37227 > 10.0.2.15.4441: . ack 8885077 win 0 14:55:38.589613 IP 10.0.2.15.4441 > 10.0.2.2.37227: . ack 2 win 5840 14:55:38.589613 IP 10.0.2.2.37227 > 10.0.2.15.4441: . ack 8885077 win 0 14:55:38.997437 IP 10.0.2.15.4441 > 10.0.2.2.37227: . ack 2 win 5840 14:55:38.997653 IP 10.0.2.2.37227 > 10.0.2.15.4441: . ack 8885077 win 0 14:55:39.813522 IP 10.0.2.15.4441 > 10.0.2.2.37227: . ack 2 win 5840 14:55:39.813758 IP 10.0.2.2.37227 > 10.0.2.15.4441: . ack 8885077 win 0 14:55:41.445562 IP 10.0.2.15.4441 > 10.0.2.2.37227: . ack 2 win 5840 14:55:41.445769 IP 10.0.2.2.37227 > 10.0.2.15.4441: . ack 8885077 win 0 The correct behavior should be to send an RST and not an ACK. There might be several ways to correct this problem. The attached patch is one possible way to implement the RFC compliant behavior. With the patch, the tcp dump starts to look like: 15:04:34.567350 IP 10.0.2.15.4441 > 10.0.2.2.58510: P 2101533:2102993(1460) ack 1 win 5840 15:04:34.567350 IP 10.0.2.2.58510 > 10.0.2.15.4441: . ack 2102993 win 5840 15:04:34.570718 IP 10.0.2.2.58510 > 10.0.2.15.4441: F 1:1(0) ack 2102993 win 5840 15:04:34.571383 IP 10.0.2.15.4441 > 10.0.2.2.58510: . 2102993:2104453(1460) ack 1 win 5840 15:04:34.571383 IP 10.0.2.2.58510 > 10.0.2.15.4441: F 1:1(0) ack 2104453 win 4380 15:04:34.571383 IP 10.0.2.15.4441 > 10.0.2.2.58510: P 2104453:2105345(892) ack 1 win 5840 15:04:34.571383 IP 10.0.2.2.58510 > 10.0.2.15.4441: F 1:1(0) ack 2105345 win 3488 15:04:34.571383 IP 10.0.2.15.4441 > 10.0.2.2.58510: . ack 2 win 5840 15:04:34.571383 IP 10.0.2.15.4441 > 10.0.2.2.58510: . ack 2 win 5840 15:04:34.571383 IP 10.0.2.2.58510 > 10.0.2.15.4441: R 12032003:12032003(0) win 3488 Also with the patch, the SIG_PIPE handlers start to work correctly in the guest OS. Thanks, Jason. --------------020401040602040504050408 Content-Type: text/x-diff; name="tcp_rst_fin_wait_2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_rst_fin_wait_2.patch" From: Jason Wessel Subject: [PATCH] slirp: Fix broken RST response to a slirp redirect socket When using slirp networking with a redirected tcp socket, the qemu guest os does not receive RST packets when a redirected, accepted socket goes into the FIN_WAIT_2 status. Presently slirp sends ACKs instead of RST packets, which means the guest os application socket writes do not fail event after the client has terminated the socket. This patch changes the behavior to correctly send RST packets instead of ACKS. Signed-off-by: Jason Wessel --- slirp/tcp_input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/slirp/tcp_input.c +++ b/slirp/tcp_input.c @@ -432,7 +432,7 @@ findso: tp = sototcpcb(so); /* XXX Should never fail */ - if (tp == 0) + if (tp == 0 || tp->t_state == TCPS_FIN_WAIT_2) goto dropwithreset; if (tp->t_state == TCPS_CLOSED) goto drop; --------------020401040602040504050408--