public inbox for passt-user@passt.top
 help / color / mirror / Atom feed
* 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
  0 siblings, 1 reply; 2+ 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] 2+ 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
  0 siblings, 0 replies; 2+ 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] 2+ messages in thread

end of thread, other threads:[~2026-09-01 18:56 UTC | newest]

Thread overview: 2+ 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

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).