ebtables can not rename just created chain

Bug #1904192 reported by Christian Ehrhardt 
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
iptables
Unknown
Unknown
iptables (Debian)
Fix Released
Unknown
iptables (Fedora)
Fix Committed
High
iptables (Ubuntu)
Fix Released
Undecided
Alex Murray
Groovy
Fix Released
Undecided
Alex Murray
Hirsute
Fix Released
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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in iptables (Ubuntu):
status: New → Confirmed
Revision history for this message
Oibaf (oibaf) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) 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?

Revision history for this message
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

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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
Revision history for this message
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
Revision history for this message
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)
Revision history for this message
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
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Christian, or anyone else affected,

Accepted iptables into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iptables/1.8.5-3ubuntu2.20.10.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in iptables (Ubuntu Groovy):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-groovy
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Bfore upgrade:

ubuntu@g-test:~$ sudo ebtables -t nat -N foo
ubuntu@g-test:~$ sudo ebtables -t nat -E foo bar
ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists
Try `ebtables -h' or 'ebtables --help' for more information.

Upgrade:
ubuntu@g-test:~$ sudo apt install iptables
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libip4tc2 libip6tc2 libxtables12
Suggested packages:
  firewalld nftables
The following packages will be upgraded:
  iptables libip4tc2 libip6tc2 libxtables12
4 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
Need to get 498 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 iptables amd64 1.8.5-3ubuntu2.20.10.2 [432 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libxtables12 amd64 1.8.5-3ubuntu2.20.10.2 [28.7 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libip6tc2 amd64 1.8.5-3ubuntu2.20.10.2 [19.1 kB]
Get:4 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libip4tc2 amd64 1.8.5-3ubuntu2.20.10.2 [18.7 kB]
Fetched 498 kB in 0s (1465 kB/s)
(Reading database ... 64660 files and directories currently installed.)
Preparing to unpack .../iptables_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking iptables (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ...
Preparing to unpack .../libxtables12_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking libxtables12:amd64 (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ...
Preparing to unpack .../libip6tc2_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking libip6tc2:amd64 (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ...
Preparing to unpack .../libip4tc2_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking libip4tc2:amd64 (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ...
Setting up libip4tc2:amd64 (1.8.5-3ubuntu2.20.10.2) ...
Setting up libip6tc2:amd64 (1.8.5-3ubuntu2.20.10.2) ...
Setting up libxtables12:amd64 (1.8.5-3ubuntu2.20.10.2) ...
Setting up iptables (1.8.5-3ubuntu2.20.10.2) ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for libc-bin (2.32-0ubuntu3) ...

After upgrade
ubuntu@g-test:~$ sudo ebtables -t nat -N foo2
ubuntu@g-test:~$ sudo ebtables -t nat -E foo2 bar
<works>

Thanks, setting verified!

tags: added: verification-done verification-done-groovy
removed: verification-needed verification-needed-groovy
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for iptables has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package iptables - 1.8.5-3ubuntu2.20.10.2

---------------
iptables (1.8.5-3ubuntu2.20.10.2) groovy; 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:40:30 +1030

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

Other bug subscribers

Remote bug watches

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