From: "Edgar E. Iglesias" <edgar.iglesias@axis.com>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Proposed fix broken RST response to a slirp redirect socket
Date: Wed, 11 Jun 2008 20:07:39 +0200 [thread overview]
Message-ID: <20080611180739.GA20729@edgar.se.axis.com> (raw)
In-Reply-To: <485009A9.6000900@windriver.com>
On Wed, Jun 11, 2008 at 12:21:45PM -0500, Jason Wessel wrote:
>
> 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
Hello Jason,
IIRC connections in FIN_WAIT_2 can continue to receive data.
If I might take a wild guess at whats going on:
The host closed the receiving socket when you ctrl-c nc. That socket still has
data in it's rcvbuf so the stack aborts the connection and sends a RST. The
slirp code should now see a -1 on it's next write to that socket and an errno
ECONNRESET but it's not correctly taking care of that case, instead it's
incorrectly setting the TCP state to FIN_WAIT_2. It should have set it to
CLOSED and sent a RST to the guest.
Best regards
>
>
> 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.
> From: Jason Wessel <jason.wessel@windriver.com>
> 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 <jason.wessel@windriver.com>
>
> ---
> 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;
--
Edgar E. Iglesias
Axis Communications AB
next prev parent reply other threads:[~2008-06-11 18:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 17:21 [Qemu-devel] [PATCH] Proposed fix broken RST response to a slirp redirect socket Jason Wessel
2008-06-11 18:07 ` Edgar E. Iglesias [this message]
2008-06-11 19:37 ` Edgar E. Iglesias
2008-06-11 20:10 ` Jason Wessel
2008-06-11 20:29 ` Edgar E. Iglesias
2008-06-11 21:14 ` Jason Wessel
2008-06-11 21:47 ` [Qemu-devel] [PATCH] slirp: Propagate host TCP RST to the guest Edgar E. Iglesias
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080611180739.GA20729@edgar.se.axis.com \
--to=edgar.iglesias@axis.com \
--cc=jason.wessel@windriver.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.