Linux Netfilter development
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Dave Pifke <dave@pifke.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] src: try SO_SNDBUF before SO_SNDBUFFORCE
Date: Sun, 9 Apr 2023 01:09:04 +0200	[thread overview]
Message-ID: <ZDH0EJN9O0DrWp0W@calendula> (raw)
In-Reply-To: <87wn2n8ghs.fsf@stabbing.victim.com>

Hi again,

Let me revisit this.

On Fri, Apr 07, 2023 at 04:21:57PM -0600, Dave Pifke wrote:
> Prior to this patch, nft inside a systemd-nspawn container was failing
> to install my ruleset (which includes a large-ish map), with the error
> 
> netlink: Error: Could not process rule: Message too long
> 
> strace reveals:
> 
> setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [524288], 4) = -1 EPERM (Operation not permitted)
>
> This is despite the nspawn process supposedly having CAP_NET_ADMIN,
> and despite /proc/sys/net/core/wmem_max (in the main host namespace)
> being set larger than the requested size:
> 
> net.core.wmem_max = 16777216

OK, so you indeed increased net.core.wmem_max on the host namespace.

> A web search reveals at least one other user having the same issue:
> 
> https://old.reddit.com/r/Proxmox/comments/scnoav/lxc_container_debian_11_nftables_geoblocking/
> 
> After this patch, nft succeeds.
> ---
>  src/mnl.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/mnl.c b/src/mnl.c
> index 26f943db..ab6750c8 100644
> --- a/src/mnl.c
> +++ b/src/mnl.c
> @@ -260,6 +260,13 @@ static void mnl_set_sndbuffer(const struct mnl_socket *nl,
>  		return;
>  
>  	/* Rise sender buffer length to avoid hitting -EMSGSIZE */
> +	if (setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_SNDBUF,
> +		       &newbuffsiz, sizeof(socklen_t)) == 0)
> +		return;

setsockopt() with SO_SNDBUF never fails: it trims the newbuffsiz that is
specified by net.core.wmem_max

This needs to call:

	setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_SNDBUF,
		   &newbuffsiz, sizeof(socklen_t));

without checking the return value. Otherwise, SO_SNDBUFFORCE is never
going to be called after this patch. This needs a v2.

On top of this patch, you still needed to increase net.core.wmem_max
in your host container for this to work.

> +	/* If the above fails (probably because it exceeds
> +	 * /proc/sys/net/core/wmem_max), try again with SO_SNDBUFFORCE.
> +	 * This requires CAP_NET_ADMIN. */
>  	if (setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_SNDBUFFORCE,
>  		       &newbuffsiz, sizeof(socklen_t)) < 0)
>  		return;
> -- 
> 2.20.1
> 

  parent reply	other threads:[~2023-04-08 23:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-07 22:21 [PATCH] src: try SO_SNDBUF before SO_SNDBUFFORCE Dave Pifke
2023-04-08 18:23 ` Pablo Neira Ayuso
2023-04-08 18:34   ` Dave Pifke
2023-04-08 23:09 ` Pablo Neira Ayuso [this message]
2023-04-10  9:04   ` Pablo Neira Ayuso
2023-04-10 18:03   ` Dave Pifke
2023-04-18 10:10     ` Pablo Neira Ayuso

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=ZDH0EJN9O0DrWp0W@calendula \
    --to=pablo@netfilter.org \
    --cc=dave@pifke.org \
    --cc=netfilter-devel@vger.kernel.org \
    /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