Proposed 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.

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 <[email protected]>
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 <[email protected]>

---
 slirp/tcp_input.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

slirp/tcp_input.c +1 -1

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

Quoted 10 lines · Jason Wessel

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:

Quoted 8 lines

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

Quoted 22 lines · Edgar E. Iglesias

Quoted 9 lines · Jason Wessel

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:

Quoted 8 lines

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

Quoted 7 lines

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.

Heh, that guess wasn't entirely correct...
Anyway, here is a patch that hopefully helps.

Best regards

slirp/socket.c +4 -1

+			int err;
+			socklen_t slen;
+
+			err = errno;
 
---

Probably don't need to set err to errno since you are collecting it with getsockopt

---

(quoted diff) +3 -1

+			if (nn == 0)
+				getsockopt(so->s, SOL_SOCKET, SO_ERROR,
+					   &err, &slen);
 
---

In theory you are supposed to set slen = sizeof(err); prior to calling getsockopt()

Quoted 5 lines · Jason Wessel

slirp/socket.c +4 -0

+			int err;
+			socklen_t slen;
+
+			err = errno;

Quoted 4 lines

---

Probably don't need to set err to errno since you are collecting it with getsockopt

Please note that the errno value is used when nn < 0.