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
>
next prev 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