public inbox for passt-user@passt.top
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Rahul <llvm.zentrik@gmail.com>, passt-user@passt.top
Subject: Re: UDP drops when source port is in use in the init namespace
Date: Wed, 2 Sep 2026 19:09:15 +1000	[thread overview]
Message-ID: <apfnutmZnc-mY3AF@gractus.seuss> (raw)
In-Reply-To: <178828896845.2775.7538203367154726506@maja>

[-- 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 --]

      parent reply	other threads:[~2026-09-02  9:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-30 10:12 Rahul
2026-09-01 18:56 ` Stefano Brivio
     [not found] ` <178828896845.2775.7538203367154726506@maja>
2026-09-02  9:09   ` David Gibson [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=apfnutmZnc-mY3AF@gractus.seuss \
    --to=david@gibson.dropbear.id.au \
    --cc=llvm.zentrik@gmail.com \
    --cc=passt-user@passt.top \
    --cc=sbrivio@redhat.com \
    /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).