Hi,

Yes, ebtables-nft does not support the atomic commands. Restoring a dump via
ebtables-restore is atomic per table due to transactional commit in kernel. So
technically, the atomic commands are not needed.

Do you have a use-case for them or are you merely trying to keep old scripts
running?

And yes, ebtables-nft.8 should not pretend things are working when they don't.

Cheers, Phil

Well, we just have legacy scritps that utilize atomic options.

(In reply to Denis Silakov from comment #2)
> Well, we just have legacy scritps that utilize atomic options.

OK. Is it an option for you to adjust those scripts to just use ebtables-save
and ebtables-restore? Unless I'm mistaken, the atomic-* options are just a
cryptic alternative to those given that atomicity is inherently guaranteed by
ebtables-nft.

I'm asking because the functionality is also not present upstream and assuming
the above is correct, upstream is likely to push back. We could try to
implement the atomic-* options as internal frontends to ebtables-save and
-restore, but that means atomic-files are not compatible to legacy ebtables. So
not a perfect alternative, either.

Just in case, are you working with legacy atomic-files or can we assume they
are always created by the same ebtables variant which is using them?

Thanks for the answer, we are curently invesitating how these options/commands are used at our side and if we can safely avoid them.

For your (and my) reference:

All commands operate per-table, i.e. '-t' parameter is respected (unlike with
ebtables-save).

--atomic-file defines the file to use - alternatively use EBTABLES_ATOMIC_FILE
environment variable.

--atomic-init stores the default set of base chains for the current table into
atomic-file.

--atomic-save stores the current table's set of chains and rules into
atomic-file (i.e. ebtables-save for a specific table).

--atomic-commit commits the content of atomic-file to kernel (i.e.
ebtables-restore).

Adding --atomic-file parameter to any command applies it to the atomic-file. A
simple (yet imperfect) way to mimick this is to just append the given command
line to the file (in ebtables-save format).

Well, we have finally managed to get rid of --atomic* usage.

So the only claim left here is that man pages still provides incorrect examples.

(In reply to Denis Silakov from comment #6)
> Well, we have finally managed to get rid of --atomic* usage.
> 
> So the only claim left here is that man pages still provides incorrect
> examples.

Great, thanks for the update.

Patch sent upstream: https://lore.kernel.org/netfilter-devel/20210728155643.31855-1-phil@nwl.cc/

Upstream commit to backport:

commit 765bf04ecc228783cb88c810c85bc0c769579c39 (HEAD -> upstream, origin-rw/master)
Author: Phil Sutter <phil>
Date:   Wed Jul 28 17:53:53 2021 +0200

    doc: ebtables-nft.8: Adjust for missing atomic-options
    
    Drop any reference to them (and the environment variable) but list them
    in BUGS section hinting at ebtables-save and -restore tools.
    
    Fixes: 1939cbc25e6f5 ("doc: Adjust ebtables man page")
    Signed-off-by: Phil Sutter <phil>
    Acked-by: Pablo Neira Ayuso <pablo>

I think this backport should also include the following commit which removes
--atomic-* from `ebtables --help` output as well:

commit 263186372dc4
Author: Phil Sutter <phil>
Date:   Fri Jul 30 12:25:10 2021 +0200

    ebtables: Dump atomic waste

    With ebtables-nft.8 now educating people about the missing
    functionality, get rid of atomic remains in source code. This eliminates
    mostly comments except for --atomic-commit which was treated as alias of
    --init-table. People not using the latter are probably trying to
    atomic-commit from an atomic-file which in turn is not supported, so no
    point keeping it.

    Signed-off-by: Phil Sutter <phil>

(In reply to Štěpán Němec from comment #11)
> I think this backport should also include the following commit which removes
> --atomic-* from `ebtables --help` output as well:

ACK, thanks for the heads-up!

https://src.osci.redhat.com/rpms/iptables/pull-request/17

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (iptables bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2002