From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: migrate/bidirectional debugging
Date: Fri, 7 Feb 2025 07:51:15 +0100 [thread overview]
Message-ID: <20250207075115.78b6e1da@elisabeth> (raw)
In-Reply-To: <Z6WnmyqIgPkRgV-T@zatzit>
On Fri, 7 Feb 2025 17:26:35 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> It kind of seemed like we were sendmsg()ing "and from guest 2" and it
> was bouncing straight back to our socket, instead of being delivered
> to the outer pasta.
Oops.
diff --git a/tcp.c b/tcp.c
index 0f05011..b7f5169 100644
--- a/tcp.c
+++ b/tcp.c
@@ -2796,6 +2796,12 @@ static int tcp_flow_repair_queues(int s,
debug("Read socket %i receive queue: %zi bytes", s, rc);
}
+ v = TCP_NO_QUEUE;
+ if (setsockopt(s, SOL_TCP, TCP_REPAIR_QUEUE, &v, sizeof(v))) {
+ err_perror("Setting TCP_NO_QUEUE on socket %i", s);
+ return -errno;
+ }
+
return 0;
}
otherwise, I guess, there's a time window in which we might be writing
that message to our queue instead of writing it on the socket, even
with repair mode off. The write might be pending or something.
With this, the stray packet is gone. I spotted this case now:
$ tshark -r test/test_logs/passt_2.pcap
1 0.000000 88.198.0.164 → 169.254.1.1 TCP 71 58150 → 10006 [PSH, ACK] Seq=1 Ack=1 Win=1024 Len=17
2 0.000031 88.198.0.164 → 169.254.1.1 TCP 54 58150 → 10006 [FIN, ACK] Seq=18 Ack=1 Win=1024 Len=0
3 0.000059 169.254.1.1 → 88.198.0.164 TCP 54 10006 → 58150 [RST, ACK] Seq=1 Ack=1 Win=256 Len=0
4 0.026443 169.254.1.1 → 88.198.0.164 TCP 74 48150 → 10001 [PSH, ACK] Seq=1 Ack=1 Win=256 Len=20
5 0.026538 88.198.0.164 → 169.254.1.1 TCP 54 10001 → 48150 [ACK] Seq=1 Ack=21 Win=1023 Len=0
6 0.026557 169.254.1.1 → 88.198.0.164 TCP 54 48150 → 10001 [FIN, ACK] Seq=21 Ack=1 Win=256 Len=0
7 0.026656 88.198.0.164 → 169.254.1.1 TCP 54 10001 → 48150 [FIN, ACK] Seq=1 Ack=22 Win=1024 Len=0
8 0.026675 169.254.1.1 → 88.198.0.164 TCP 54 48150 → 10001 [ACK] Seq=22 Ack=2 Win=256 Len=0
9 318.959707 fe80::1 → ff02::1 ICMPv6 158 Router Advertisement from 9a:55:9a:55:9a:55
That RST we send as frame #3 looks unwarranted. I wonder if we get
packets from the target guest before we have a chance to set up flows.
--
@@ -2796,6 +2796,12 @@ static int tcp_flow_repair_queues(int s,
debug("Read socket %i receive queue: %zi bytes", s, rc);
}
+ v = TCP_NO_QUEUE;
+ if (setsockopt(s, SOL_TCP, TCP_REPAIR_QUEUE, &v, sizeof(v))) {
+ err_perror("Setting TCP_NO_QUEUE on socket %i", s);
+ return -errno;
+ }
+
return 0;
}
otherwise, I guess, there's a time window in which we might be writing
that message to our queue instead of writing it on the socket, even
with repair mode off. The write might be pending or something.
With this, the stray packet is gone. I spotted this case now:
$ tshark -r test/test_logs/passt_2.pcap
1 0.000000 88.198.0.164 → 169.254.1.1 TCP 71 58150 → 10006 [PSH, ACK] Seq=1 Ack=1 Win=1024 Len=17
2 0.000031 88.198.0.164 → 169.254.1.1 TCP 54 58150 → 10006 [FIN, ACK] Seq=18 Ack=1 Win=1024 Len=0
3 0.000059 169.254.1.1 → 88.198.0.164 TCP 54 10006 → 58150 [RST, ACK] Seq=1 Ack=1 Win=256 Len=0
4 0.026443 169.254.1.1 → 88.198.0.164 TCP 74 48150 → 10001 [PSH, ACK] Seq=1 Ack=1 Win=256 Len=20
5 0.026538 88.198.0.164 → 169.254.1.1 TCP 54 10001 → 48150 [ACK] Seq=1 Ack=21 Win=1023 Len=0
6 0.026557 169.254.1.1 → 88.198.0.164 TCP 54 48150 → 10001 [FIN, ACK] Seq=21 Ack=1 Win=256 Len=0
7 0.026656 88.198.0.164 → 169.254.1.1 TCP 54 10001 → 48150 [FIN, ACK] Seq=1 Ack=22 Win=1024 Len=0
8 0.026675 169.254.1.1 → 88.198.0.164 TCP 54 48150 → 10001 [ACK] Seq=22 Ack=2 Win=256 Len=0
9 318.959707 fe80::1 → ff02::1 ICMPv6 158 Router Advertisement from 9a:55:9a:55:9a:55
That RST we send as frame #3 looks unwarranted. I wonder if we get
packets from the target guest before we have a chance to set up flows.
--
Stefano
prev parent reply other threads:[~2025-02-07 6:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 6:26 migrate/bidirectional debugging David Gibson
2025-02-07 6:51 ` Stefano Brivio [this message]
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=20250207075115.78b6e1da@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/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.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).