* UDP drops when source port is in use in the init namespace
@ 2026-08-30 10:12 Rahul
2026-09-01 18:56 ` Stefano Brivio
[not found] ` <178828896845.2775.7538203367154726506@maja>
0 siblings, 2 replies; 3+ messages in thread
From: Rahul @ 2026-08-30 10:12 UTC (permalink / raw)
To: passt-user
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
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;
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.
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.
I'm not sure whether this is intended, but if it is, is there any way to
work
around it?
Thanks
[-- Attachment #2: Type: text/html, Size: 911 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: UDP drops when source port is in use in the init namespace 2026-08-30 10:12 UDP drops when source port is in use in the init namespace Rahul @ 2026-09-01 18:56 ` Stefano Brivio [not found] ` <178828896845.2775.7538203367154726506@maja> 1 sibling, 0 replies; 3+ messages in thread From: Stefano Brivio @ 2026-09-01 18:56 UTC (permalink / raw) To: Rahul; +Cc: passt-user 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <178828896845.2775.7538203367154726506@maja>]
* Re: UDP drops when source port is in use in the init namespace [not found] ` <178828896845.2775.7538203367154726506@maja> @ 2026-09-02 9:09 ` David Gibson 0 siblings, 0 replies; 3+ messages in thread From: David Gibson @ 2026-09-02 9:09 UTC (permalink / raw) To: Stefano Brivio; +Cc: Rahul, passt-user [-- Attachment #1: Type: text/plain, Size: 4131 bytes --] On Tue, Sep 01, 2026 at 08:56:01PM +0200, Stefano Brivio via user wrote: > Date: Tue, 01 Sep 2026 20:56:01 +0200 (CEST) > 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 > Organization: Red Hat > List-Id: "For passt users: support, questions and answers" > <passt-user.passt.top> > > 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. Probably? The danger with a fallback of this sort is that if you're using a protocol which cares about the source port it will work.. until suddenly it doesn't for pretty non-obvious reasons. Theoretically another option would be to _not_ preserve the source port by default, but allow forwarding rules to specify source-port preservation, specifically for cases which do need it. But, that's a lot more work both to implement and to configure. > > 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). You'll also need to make sure this takes place _before_ calling getsockname() to fill in the correct final tgt->oport. > 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 > > _______________________________________________ > user mailing list -- passt-user@passt.top > To unsubscribe send an email to passt-user-leave@passt.top -- 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-02 9:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-30 10:12 UDP drops when source port is in use in the init namespace Rahul
2026-09-01 18:56 ` Stefano Brivio
[not found] ` <178828896845.2775.7538203367154726506@maja>
2026-09-02 9:09 ` David Gibson
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).