On Wed, Feb 05, 2025 at 01:39:04AM +0100, Stefano Brivio wrote:This implements flow preparation on the source, transfer of data with a format roughly inspired by struct tcp_tap_conn, and flow insertion on the target, with all the appropriate window options, window scaling, MSS, etc. The target side is rather convoluted because we first need to create sockets and switch them to repair mode, before we can apply options that are *not* stored in the flow table. However, we don't want to request repair mode for sockets one by one. So we need to do this in several steps. A hack in order to connect() on the "RARP" message should be easy to enable, I left a couple of comments in that sense. This is very much draft quality, but I tested the whole flow, and it works for me. Window parameters and MSS match, too. Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>[snip]diff --git a/isolation.c b/isolation.c index c944fb3..df58bb8 100644 --- a/isolation.c +++ b/isolation.c @@ -377,7 +377,7 @@ void isolate_postfork(const struct ctx *c) { struct sock_fprog prog; - prctl(PR_SET_DUMPABLE, 0); +// prctl(PR_SET_DUMPABLE, 0);Looks like a stray debugging change made it in here. Fwiw, I keep a branch around with debugging hacks including exactly this. To make it harder to accidentally leak debug hacks into "real" series, I usually rebase between my debugging branch and main. In this case it conflicted with the patch from my debugging branch, of course, which is why I spotted it.switch (c->mode) { case MODE_PASST:-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson