ebtables can not rename just created chain

Bug #1904192 reported by Christian Ehrhardt  on 2020-11-13
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
iptables
Unknown
Unknown
iptables (Debian)
Unknown
Unknown
iptables (Fedora)
Fix Committed
High
iptables (Ubuntu)
Status tracked in Hirsute
Groovy
Undecided
Alex Murray
Hirsute
Undecided
Alex Murray

Bug Description

[SRU]

 * Changes that went into 1.8.5 ave broken the errno handling.
   In particular loading extensions. Due to that it has become
   impossible to rename rules.

 * Upstream has created a fix and this backports that change to
   Ubuntu
   => http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

[Test Case]

 * # ebtables -t nat -N foo
   # ebtables -t nat -E foo bar
   ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists

 * with the fix the above command sequence works

[Where problems could occur]

 * The change moved code from nft_chain_user_rename to do_commandeb and
   therefore in theory any ebtables/xtables subcommand could be affected.
   Yet what it does is just resetting the error code in a better place, so
   while it "could" affect every subcommand it should (tm) not do so.

[Other Info]

 * n/a

---

Hi,
I have an issue with ebtables that affects libvirt.
While initially found in hirsute I had to realize this is broken in
Groovy and even Bionic (might be a different reason back then) as well right now.
But working in Focal (witch matches my memory of it being good before [1]).

I was isolating the commands that libvirt runs (identical between Focal
and Hirsute) to find a simplified trigger. Gladly I found one that leaves
libvirt and other components out of the equation.
The following works on focal, but fails on the other releases.

Note: I checked which tool is in use and in both cases it is xtables-nft-multi.
/usr/sbin/ebtables -> /etc/alternatives/ebtables*
/etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
/usr/sbin/ebtables-nft -> xtables-nft-multi*
So I converted the libvirt issued commands into xtables-nft-multi just to be
sure in case a system to compare has other alternatives set.

Focal (Good):
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed
<system is happy>

Groovy/Hirsute (Fail):
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed
ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
Try `ebtables -h' or 'ebtables --help' for more information.

What might be the root cause for this?

-- Old test instructions --

As I said I was tracking a fail in libvirt so the test instructions initially
were around that:

# the following us done as 2nd level guest (to not mess with the host,
# but works on bare metal jst as much)
uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
# On guest then

sudo apt update
sudo apt install uvtool uvtool-libvirt
uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
uvt-kvm wait hirsute-2nd-lvm
virsh shutdown hirsute-2nd-lvm
virsh edit hirsute-2nd-lvm
# add this to the network
      <filterref filter='clean-traffic'>
        <parameter name='CTRL_IP_LEARNING' value='dhcp'/>
      </filterref>
virsh start hirsute-2nd-lvm
  error: Failed to start domain hirsute-2nd-nwfilter
  error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
log_filters="1:util.firewall"
log_outputs="1:syslog:libvirtd"

-- --

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in iptables (Ubuntu):
status: New → Confirmed
Oibaf (oibaf) wrote :

FYI
Since I started on this with libvirt and the libvirt people were helpful as always in debugging this I also pinged the ML since this issue should affect libvirt in any place where it runs with the new ebtables.
https://www.redhat.com/archives/libvir-list/2020-November/msg00790.html

@Oibaf - thanks for reporting this upstream. Does it affect you in another use-case/context than libvirt?

Oibaf (oibaf) wrote :

Actually I am not affected by this specific bug, but I am interested in every regressions because I plan to move a massive firewall from the -legacy version to the -nft one.

Another good place to report this issue is on the netfilter-devel ML: https://netfilter.org/mailinglists.html#ml-devel

FYI: via the libvirt discussion it was reported that
- legacy 2.0.11 works on fedora (for us as well on Ubuntu)
- 1.8.4 works on RHEL8 (we have 1.8.5 that fails)

Changed in iptables (Fedora):
importance: Unknown → High
status: Unknown → Confirmed

The issue was confirmed and a fix now committed to the upstream repository.
=> http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

@Alex will you (as usual) do the upload of that - will eventually be Groovy and Hirsute that needs this.

description: updated
Alex Murray (alexmurray) wrote :

Yep I'll take this @Christian

Changed in iptables (Ubuntu Groovy):
assignee: nobody → Alex Murray (alexmurray)
Changed in iptables (Ubuntu Groovy):
status: New → In Progress
Changed in iptables (Fedora):
status: Confirmed → Fix Committed
Jamie Strandboge (jdstrand) wrote :

FYI, sponsored Alex's upload to hirsute-proposed where it is building. Did the same for groovy-proposed and it is sitting in unapproved waiting for the next steps of the SRU process.

Changed in iptables (Ubuntu):
status: Confirmed → Fix Committed
assignee: nobody → Alex Murray (alexmurray)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package iptables - 1.8.5-3ubuntu4

---------------
iptables (1.8.5-3ubuntu4) hirsute; urgency=medium

  * Fix regression in ebtables when renaming a chain (LP: #1904192)
    - d/p/9004-ebtables-fix-for-broken-chain-rename.patch: Backport patch
      from upstream to fix improper use of errno to indicate failure when
      renaming an existing chain.

 -- Alex Murray <email address hidden> Wed, 18 Nov 2020 11:36:27 +1030

Changed in iptables (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.