From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Fcp/ZQsW; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id E21C85A0625 for ; Tue, 13 Jan 2026 23:13:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768342420; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9dBaj01CgPOpiC0fu49R8VcKjOPv5RXhOkhCvAYwH3Q=; b=Fcp/ZQsWDZ7ygnjBSeFvINsy26PG4p8k86Ziajp/2uI+uZ0D9uGP4tuCeyS939HqnnyMIO c4Kt5ojxK8npWP1dHDHZFDVK+z1BrU5XwlnJvhmquZ2TYnPO1DEVi3a8TEmskPYsHGzZC1 MChDbVcz9Dtdy1Yga2dBoejXRe7rc0g= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-138-TwQjEWNBPRifvpkY_TeZrg-1; Tue, 13 Jan 2026 17:13:39 -0500 X-MC-Unique: TwQjEWNBPRifvpkY_TeZrg-1 X-Mimecast-MFC-AGG-ID: TwQjEWNBPRifvpkY_TeZrg_1768342418 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4775f51ce36so73595965e9.1 for ; Tue, 13 Jan 2026 14:13:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768342418; x=1768947218; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9dBaj01CgPOpiC0fu49R8VcKjOPv5RXhOkhCvAYwH3Q=; b=PG42cIfLdpn1M0Zp3kb4MAGNrAfYZPD1DfVVvf/GBwrP4E867YkgxrdeDwKGD2F4oG nZzbOoYaqWx+2qzJeo/iWyk1ty+hfDdSE5LJDN71caWaj14WFiNVFz1tqn1fOeFoxsIx RDrXo+SpGjjiHThBY8598WczaituckoZOkQ6Q9Rodkyw/k53/HHralRlZF/zGJ1oK6M7 1EcgbFufTB0r3+X4PuYJOBIYBnIaVvki/cdxDmlEKbrmeJuJpz9qBQI5twETXnuGSZir el1M1STppt1ReooX730m0GkAdnyRCC77BGqRepShguq7AOaWyuOuqEf8CSgZMTQ0YJSc y4RA== X-Gm-Message-State: AOJu0YwRPIjGyg2TKnMXA7e+xaJrrKvkvZVerpMjvDo+5TE1Q7zQD7he Rvph+hn5BvEcfBHbhnTKtuat5nXP+1Xr/Er4l1pdxPMPBzgsy88g9I91U3IeIeC0QATYZ6UxDni kKz9BJCQ42GbicYyfZB5ZqgfQWFiQkQEroOCPhZYPAugRk2nqsfrKSg== X-Gm-Gg: AY/fxX5wMg1k9NW0sKUWbXZ/Ov8np3jF5i5SrjoNM6igcYJOshcGcp4eMiGM/uK4iBq igwCE/Nc5vJ56qKN/MgLLMojxCSh/OmY/T1TiWihbNIcEw/7qanvcMflisK0hysOPkbfLjYfINY ifqDoR5f4JWWjvJ+57V+K32+IMPDYOn6ucqgI2NiWaEeFvapnabNxtCPy9f2dzAM8turYMIz15T QVOLqSnpx66WAAeVx//74Mi7b+bICgftUfFB9zlyKNBkr/MDscdWrkx+x8OBKJZGapPHUb4VLYR OuSrSWMiNGSomzjIssZ6UamDsa8n3WeyK8/6n5wN2Wb40t1LcFy+XkRK8CYCwdpGa3BwHlMGkjp F3HTFdQgy4lJNBMcGkqtOPRBtqmuCWsWEX3gyCA== X-Received: by 2002:a05:600c:c8d:b0:46e:59bd:f7d3 with SMTP id 5b1f17b1804b1-47ee33768c9mr6277105e9.20.1768342418445; Tue, 13 Jan 2026 14:13:38 -0800 (PST) X-Received: by 2002:a05:600c:c8d:b0:46e:59bd:f7d3 with SMTP id 5b1f17b1804b1-47ee33768c9mr6276965e9.20.1768342417995; Tue, 13 Jan 2026 14:13:37 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f7035f2sm408021085e9.12.2026.01.13.14.13.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 14:13:37 -0800 (PST) Date: Tue, 13 Jan 2026 23:13:36 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 07/14] fwd, tcp, udp: Set up listening sockets based on forward table Message-ID: <20260113231336.0711e84a@elisabeth> In-Reply-To: References: <20260108022948.2657573-1-david@gibson.dropbear.id.au> <20260108022948.2657573-8-david@gibson.dropbear.id.au> <20260113002636.43c77c0a@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: R49UbJ4_Qew5AJzzk2C0Qd317tpa2Hc_M_K-IYfxFCA_1768342418 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: CEA53NZ7B7QASARY4WC55NRNQM5W5NQP X-Message-ID-Hash: CEA53NZ7B7QASARY4WC55NRNQM5W5NQP X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 13 Jan 2026 16:38:58 +1100 David Gibson wrote: > On Tue, Jan 13, 2026 at 12:26:36AM +0100, Stefano Brivio wrote: > > On Thu, 8 Jan 2026 13:29:41 +1100 > > David Gibson wrote: > > > > > Previously we created inbound listening sockets as we parsed the forwarding > > > options (-t, -u) whereas outbound listening sockets were created during > > > {tcp,udp}_init(). Now that we have a data structure recording the full > > > details of the listening options we can move all listening socket creation > > > to {tcp,udp}_init(). This means that errors for either direction are > > > detected and reported the same way. > > > > > > Introduce fwd_listen_sync() which synchronizes the state of listening > > > sockets to the forwarding rules table, both for fixed and automatic > > > forwards. > > > > > > This does cause a change in semantics for "exclude only" port > > > specifications. Previously an option like -t ~6000 wouldn't cause a > > > fatal error, as long as we could bind at least one port. Now, it > > > requires at least one port for each generated rule; that is for each > > > of the contiguous blocks of ports the specification resolves to. With > > > typical ephemeral ports settings that's one port each in 1..5999, > > > 6001..32767 and 61000..65535. > > > > > > Preserving the exact behaviour for this case would require a considerably > > > more complex data structure, so I'm hoping this is a sufficiently niche > > > case for the change to be acceptable. > > > > I guess so too, I wouldn't really worry. > > > > Well, I'm not sure if it works, but one relatively simple idea could be > > to have a "with_prev" bit in the rule struct representing the fact that > > the current rule was derived from the same port specification as the > > previous rule, which implies they would need to be deleted all together > > (but we can happily enforce that). > > > > Then, in the fwd_listen_sync_() loop, before reporting failure, you > > would check the next entry: if the "with_prev" bit is set, report > > failure only if we fail (keeping a local boolean flag) for all the > > entries up to the first one with "with_prev" unset. > > I'll keep that approach in mind if it seems like we need it. > > > I would be inclined to say it's worth it if it's that simple, but I > > haven't tried, so I might be very well missing something. > > I also considered making WEAK mean we'd always continue on listen > failures, even if all of them fail. Maybe that's a bit unexpected? > But it would allow an option to "forward single port X, if you can" > which seems like it might be useful. I think that's a different feature, perhaps it would need its own flag. But I don't think we should have it on by default with the current command-line interface. Perhaps the client should have a different command/specifier to add a set of ranges which can all fail entirely. But I guess it risks being a bit too much for the command line. By the way, that should make more sense once we add the possibility of specifying ports or ranges for automatic port forwarding, or for https://bugs.passt.top/show_bug.cgi?id=131, because at that point it becomes "when you can"... and we would already have that implemented, actually. -- Stefano