From: Stefano Brivio <sbrivio@redhat.com>
To: Rahul <llvm.zentrik@gmail.com>
Cc: passt-user@passt.top
Subject: Re: UDP drops when source port is in use in the init namespace
Date: Tue, 01 Sep 2026 20:56:01 +0200 (CEST) [thread overview]
Message-ID: <20260901205559.6691b499@elisabeth> (raw)
In-Reply-To: <CAOiLhOTSZuDVd79dHkdVgVurXXkr62wPTYKuD7F++47ssPeJhg@mail.gmail.com>
Rahul, thanks for the report and for the investigation. Remarks and
some answers inline:
On Sun, 30 Aug 2026 11:12:44 +0100
Rahul <llvm.zentrik@gmail.com> wrote:
> Hi,
>
> I'm seeing DNS requests being dropped when using pasta 20250217. As far as
> I can tell, UDP
> flows where the source port chosen in the namespace is already in use in the
> init namespace get dropped.
>
> All three fwd_nat_from_*() preserve the source port for UDP:
>
> tgt->oport = 0;
> if (proto == IPPROTO_UDP)
> /* But for UDP preserve the source port */
> tgt->oport = ini->eport;
This is intended, to offer compatibility with applications or protocols
that might rely on UDP source ports to be preserved, and, in general,
to be as transparent as possible. But:
> That forces a bind() to it, and udp_flow_sock() treats bind failure as
> fatal, so
> the flow is cancelled and the datagram dropped with no error to the sender.
...this is not, that is, it would definitely be desirable to have a
fallback for bind() failures.
> I don't think I ever hit this with slirp4netns, it looks like libslirp's
> udp_attach() never
> binds a port, so the kernel just gives it a random free port.
Right, yes, slirp4netns doesn't attempt to preserve UDP source ports
outside the namespace. It's a feature we added in pasta.
> I'm not sure whether this is intended, but if it is, is there any way to
> work
> around it?
I see two ways of implementing this fallback mechanism, roughly:
1. pass all the way to _sock_l4() via udp_flow_sock() an additional
argument to entirely ignore bind() failures (like we do for ICMP
ping sockets). It might be a rather mechanical change but not my
preferred approach as we would need an extra argument in a large
number of functions just for a corner case
2. I think preferable: detect the failure on bind() here (it should be
EADDRINUSE, did you check?) and try again from udp_flow_sock() with
tgt->oport as 0.
Here, "tgt" means the target namespace of the connection, and
"oport" means "our port", implying the source port (because it's an
outbound connection from pasta's side).
I think it would be good to try and sketch a solution (maybe starting
from 1.) to understand what approach would be more elegant and viable.
I don't have much time on my hands right now but I'll definitely
provide pointers and support if you feel like proposing a patch for
this.
As a first test / workaround for your usage: did you already check that
keeping tgt->oport as 0 in the relevant function in fwd.c works?
--
Stefano
prev parent reply other threads:[~2026-09-01 18:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 10:12 Rahul
2026-09-01 18:56 ` 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=20260901205559.6691b499@elisabeth \
--to=sbrivio@redhat.com \
--cc=llvm.zentrik@gmail.com \
--cc=passt-user@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.
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).