Re: netfilter: iptables-restore: setsockopt(3, SOL_IP, IPT_SO_SET_REPLACE, "security...", ...) return -EAGAIN

Hi,

On Thu, May 13, 2021 at 11:40:47AM +0200, Pablo Neira Ayuso wrote:

On Thu, May 13, 2021 at 06:19:38AM +0000, Dexuan Cui wrote:

quoted

quoted

From: Dexuan Cui
Sent: Wednesday, May 12, 2021 11:02 PM

BTW, I found a similar report in 2019:

"
https://serverfault.com/questions/101022/error-applying-iptables-rules-using-iptables-restore
I stumbled upon this issue on Ubuntu 18.04. The netfilter-persistent
service failed randomly on boot while working ok when launched manually.
Turned out it was conflicting with sshguard service due to systemd trying
to load everything in parallel. What helped is to setting
ENABLE_FIREWALL=0 in /etc/default/sshguard and then adding sshguard chain
and rule manually to /etc/iptables/rules.v4 and /etc/iptables/rules.v6.
"

The above report provided a workaround.

There's -w and -W to serialize ruleset updates. You could follow a
similar approach from userspace if you don't use iptables userspace
binary.

My guess is the xtables lock is not effective here, so waiting for it
probably won't help.

Dexuan, concurrent access is avoided in user space using a file-based
lock. So if multiple iptables(-restore) processes run in different
mount-namespaces, they might miss the other's /run/xtables.lock. Another
option would be if libiptc is used instead of calling iptables, but
that's more a shot in the dark - I don't know if libiptc doesn't support
obtaining the xtables lock.

quoted

I think we need a real fix.

iptables-nft already fixes this.

nftables (and therefore iptables-nft) implement transactional logic in
kernel, user space automatically retries if a transaction's commit
fails.

Cheers, Phil