qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH] Proposed fix broken RST response to a slirp redirec


From: Jason Wessel
Subject: [Qemu-devel] [PATCH] Proposed fix broken RST response to a slirp redirect socket
Date: Wed, 11 Jun 2008 12:21:45 -0500
User-agent: Thunderbird 2.0.0.14 (X11/20080502)

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.
From: Jason Wessel <address@hidden>
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 <address@hidden>

---
 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;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]