Bug 1674536 - incompabitility in iptables-ebtables "-L" output vs. ebtables causes scripts to fail
Summary: incompabitility in iptables-ebtables "-L" output vs. ebtables causes scripts ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: iptables
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: Phil Sutter
QA Contact: qe-baseos-daemons
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-11 15:26 UTC by Laine Stump
Modified: 2019-05-07 11:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.Output of `iptables-ebtables` is not 100% compatible with `ebtables` In RHEL 8, the `ebtables` command is provided by the `iptables-ebtables` package, which contains an `nftables`-based reimplementation of the tool. This tool has a different code base, and its output deviates in aspects, which are either negligible or deliberate design choices. Consequently, when migrating your scripts parsing some `ebtables` output, adjust the scripts to reflect the following: * MAC address formatting has been changed to be fixed in length. Where necessary, individual byte values contain a leading zero to maintain the format of two characters per octet. * Formatting of IPv6 prefixes has been changed to conform with RFC 4291. The trailing part after the slash character no longer contains a netmask in the IPv6 address format but a prefix length. This change applies to valid (left-contiguous) masks only, while others are still printed in the old formatting.
Clone Of:
Environment:
Last Closed: 2019-02-15 15:47:22 UTC
Type: Bug


Attachments (Terms of Use)

Description Laine Stump 2019-02-11 15:26:28 UTC
The output from "ebtables -L" in the the "original" ebtables package formats MAC addresses as:

    %x:%x:%x:%x:%x:%x

(e.g. "1:2:3:4:5:6") and shows IPv6 prefixes as a netmask (e.g: "/ffff:ffff:fc00::"), but the same output using the ebtables command from the iptables-ebtables package formats MAC addresses as:

   %0x:%0x:%0x:%0x:%0x:%0x

("01:02:03:04:05:06") and shows IPv6 prefixes as.... prefixes (e.g.: "/22").

While the new format is arguably "nicer", it is a change in defacto API that makes the RHEL8 ebtables -L output incompatible with what was output in previous RHEL versions, thus making it likely that shell scripts that have been running successfully for years will suddenly fail after upgrading.

iptables-ebtables should format MAC addresses and IPv6 prefixes (and everything else) exactly as it was formatted in the original ebtables.

This was found by running the libvirt-tck nwfilter tests, which are in the package perl-Sys-Virt-TCK. A RHEL8 repo of all the necessary packages to install and run this test suite are here:

   https://people.redhat.com/lstump/libvirt-tck-rhel8/

but the problem can be seen by just running the following commands and noting the difference in output from RHEL7/Fedora29 to RHEL8:

    # ebtables -t nat -A PREROUTING \
        -p IPv6 -s 4:4:4:4:4:4/ff:ff:ff:ff:ff:fe \
        -d 0:1:2:3:4:5/ff:ff:ff:ff:ff:80 \
        --ip6-src ::/ffff:fc00:: \
        --ip6-dst ::10.1.0.0/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000 \
        --ip6-proto udp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT

Here is the old output of "ebtables -t nat -L PREROUTING" (with line breaks inserted):

   -p IPv6 -s 4:4:4:4:4:4/ff:ff:ff:ff:ff:fe 
   -d 0:1:2:3:4:0/ff:ff:ff:ff:ff:80 
   --ip6-src ::/ffff:fc00:: 
   --ip6-dst ::10.1.0.0/ffff:ffff:ffff:ffff:ffff:ffff:ffff:8000 
   --ip6-proto udp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT

and here is the output when iptables-ebtables is used:

   -p IPv6 -s 04:04:04:04:04:04/ff:ff:ff:ff:ff:fe 
   -d 00:01:02:03:04:00/ff:ff:ff:ff:ff:80 
   --ip6-src ::/22 
   --ip6-dst ::10.1.0.0/113 
   --ip6-proto udp --ip6-sport 20:22 --ip6-dport 100:101 -j ACCEPT

Comment 1 Phil Sutter 2019-02-12 15:27:59 UTC
Hi Laine,

(In reply to Laine Stump from comment #0)
> The output from "ebtables -L" in the the "original" ebtables package formats
> MAC addresses as:
> 
>     %x:%x:%x:%x:%x:%x
> 
> (e.g. "1:2:3:4:5:6") and shows IPv6 prefixes as a netmask (e.g:
> "/ffff:ffff:fc00::"), but the same output using the ebtables command from
> the iptables-ebtables package formats MAC addresses as:
> 
>    %0x:%0x:%0x:%0x:%0x:%0x
> 
> ("01:02:03:04:05:06") and shows IPv6 prefixes as.... prefixes (e.g.: "/22").
> 
> While the new format is arguably "nicer", it is a change in defacto API that
> makes the RHEL8 ebtables -L output incompatible with what was output in
> previous RHEL versions, thus making it likely that shell scripts that have
> been running successfully for years will suddenly fail after upgrading.

I would even go as far as considering the old output format to be a bug which
should be fixed in legacy ebtables. :)

Regarding breaking scripts, I can't imagine the differences in mac address
output to be relevant - you'd have to account for two digits per byte anyway and
in practice to many regexps a mac address simply looks like '*:*:*:*:*:*'.

The IPv6 address mask output definitely has potential to break scripts, the
output is completely different (and has to be interpreted as such). I wonder how
many swearing and custom written prefix to mask converters this has caused.

> iptables-ebtables should format MAC addresses and IPv6 prefixes (and
> everything else) exactly as it was formatted in the original ebtables.

I agree but reintroducing stupid things for that hurts, so I would like to
assess impact first:

> This was found by running the libvirt-tck nwfilter tests, which are in the
> package perl-Sys-Virt-TCK. A RHEL8 repo of all the necessary packages to
> install and run this test suite are here:

Does libvirt depend on the output formatting of ebtables (apart from verifiers
in testsuite)? If so, what is the deadline for you to get this resolved
(RHEL8.0, 8.0.1 (what-/whenever that is), 8.1)? If not, does adjusting the
testsuite to accept the changed output constitue a workaround?

Thanks, Phil

Comment 2 Daniel Berrange 2019-02-12 17:14:50 UTC
(In reply to Phil Sutter from comment #1)
> Hi Laine,
> 
> (In reply to Laine Stump from comment #0)
> > The output from "ebtables -L" in the the "original" ebtables package formats
> > MAC addresses as:
> > 
> >     %x:%x:%x:%x:%x:%x
> > 
> > (e.g. "1:2:3:4:5:6") and shows IPv6 prefixes as a netmask (e.g:
> > "/ffff:ffff:fc00::"), but the same output using the ebtables command from
> > the iptables-ebtables package formats MAC addresses as:
> > 
> >    %0x:%0x:%0x:%0x:%0x:%0x
> > 
> > ("01:02:03:04:05:06") and shows IPv6 prefixes as.... prefixes (e.g.: "/22").
> > 
> > While the new format is arguably "nicer", it is a change in defacto API that
> > makes the RHEL8 ebtables -L output incompatible with what was output in
> > previous RHEL versions, thus making it likely that shell scripts that have
> > been running successfully for years will suddenly fail after upgrading.
> 
> I would even go as far as considering the old output format to be a bug which
> should be fixed in legacy ebtables. :)
> 
> Regarding breaking scripts, I can't imagine the differences in mac address
> output to be relevant - you'd have to account for two digits per byte anyway
> and
> in practice to many regexps a mac address simply looks like '*:*:*:*:*:*'.

Yes, I think this change is really minor / insignificant

> The IPv6 address mask output definitely has potential to break scripts, the
> output is completely different (and has to be interpreted as such). I wonder
> how many swearing and custom written prefix to mask converters this has caused.

I don't disagree that the old format was unpleasant, but it has been like
this for years now, so admins/scripts are adapted to the pain already.

If the nft based *tables commands are really intended to be a drop-in
replacement for the original xtables based impls, then this format
change is a bad idea.

> > iptables-ebtables should format MAC addresses and IPv6 prefixes (and
> > everything else) exactly as it was formatted in the original ebtables.
> 
> I agree but reintroducing stupid things for that hurts, so I would like to
> assess impact first:
> 
> > This was found by running the libvirt-tck nwfilter tests, which are in the
> > package perl-Sys-Virt-TCK. A RHEL8 repo of all the necessary packages to
> > install and run this test suite are here:
> 
> Does libvirt depend on the output formatting of ebtables (apart from
> verifiers
> in testsuite)? If so, what is the deadline for you to get this resolved
> (RHEL8.0, 8.0.1 (what-/whenever that is), 8.1)? If not, does adjusting the
> testsuite to accept the changed output constitue a workaround?

It /only/ affects the libvirt test suite when we validate the rules that
were created match what we expected to get.

If it doesn't get resolved for RHEL-8.0 GA, then we're going to have to
put a workaround in our test suite regardless, at which point fixing the
bug isn't an issue from libvirt's POV anymore.

IOW, from libvirt's POV either this change is fixed for GA, or it can be closed wontfix now.

Comment 3 Phil Sutter 2019-02-12 21:56:09 UTC
Hi Daniel,

(In reply to Daniel Berrange from comment #2)
> (In reply to Phil Sutter from comment #1)
[...]
> > Does libvirt depend on the output formatting of ebtables (apart from
> > verifiers
> > in testsuite)? If so, what is the deadline for you to get this resolved
> > (RHEL8.0, 8.0.1 (what-/whenever that is), 8.1)? If not, does adjusting the
> > testsuite to accept the changed output constitue a workaround?
> 
> It /only/ affects the libvirt test suite when we validate the rules that
> were created match what we expected to get.
> 
> If it doesn't get resolved for RHEL-8.0 GA, then we're going to have to
> put a workaround in our test suite regardless, at which point fixing the
> bug isn't an issue from libvirt's POV anymore.
> 
> IOW, from libvirt's POV either this change is fixed for GA, or it can be
> closed wontfix now.

Thanks for your validation. After studying RFC4291, I think representation of
IPv6 prefixes in netmask notation is invalid. Consequently I've sent a patch to
change this in legacy ebtables upstream:

https://marc.info/?l=netfilter-devel&m=155000828923204&w=2

If this is rejected, I'll attempt to align ebtables-nft output with legacy one.

Thanks, Phil

Comment 4 Phil Sutter 2019-02-15 15:47:22 UTC
(In reply to Phil Sutter from comment #3)
> Hi Daniel,
> 
> (In reply to Daniel Berrange from comment #2)
> > (In reply to Phil Sutter from comment #1)
> [...]
> > > Does libvirt depend on the output formatting of ebtables (apart from
> > > verifiers
> > > in testsuite)? If so, what is the deadline for you to get this resolved
> > > (RHEL8.0, 8.0.1 (what-/whenever that is), 8.1)? If not, does adjusting the
> > > testsuite to accept the changed output constitue a workaround?
> > 
> > It /only/ affects the libvirt test suite when we validate the rules that
> > were created match what we expected to get.
> > 
> > If it doesn't get resolved for RHEL-8.0 GA, then we're going to have to
> > put a workaround in our test suite regardless, at which point fixing the
> > bug isn't an issue from libvirt's POV anymore.
> > 
> > IOW, from libvirt's POV either this change is fixed for GA, or it can be
> > closed wontfix now.
> 
> Thanks for your validation. After studying RFC4291, I think representation of
> IPv6 prefixes in netmask notation is invalid. Consequently I've sent a patch
> to
> change this in legacy ebtables upstream:
> 
> https://marc.info/?l=netfilter-devel&m=155000828923204&w=2
> 
> If this is rejected, I'll attempt to align ebtables-nft output with legacy
> one.

Upstream accepted my fix for legacy ebtables. Therefore I think we may burden
RHEL8 users with adjusting their scripts. (Which includes libvirt's testsuite.)

Comment 5 Laine Stump 2019-02-15 18:23:13 UTC
The upstream patch only "fixes" netmask/prefix formatting, but doesn't change the MAC address formatting. Do you plan to send a patch for that as well?

Comment 6 Phil Sutter 2019-02-15 22:24:10 UTC
Hi Laine,

(In reply to Laine Stump from comment #5)
> The upstream patch only "fixes" netmask/prefix formatting, but doesn't
> change the MAC address formatting. Do you plan to send a patch for that as
> well?

As pointed out in comment 1, I consider this a minor issue. Do you think
fixing the formatting in legacy ebtables is feasible?

Thanks, Phil

Comment 7 Laine Stump 2019-02-16 18:39:51 UTC
I'm not advocating one way or the other, just wondering if you had forgotten about it, or if you purposefully intended to not change it. I'm fine with it either way.

(Well, I really think variable-length MAC address strings are ugly, and it complicates our tests to have to deal with variable and fixed length MACs.(since the way the test works is 1) apply some abstract rule at a higher level (in this case libvirt's nwfilter rules), then 2) diff (i.e. a straight strcmp, not a regexp match) the output of various subsets of ebtables -L (and iptables -L and ip6tables -L) with output that was captured during a "known good" run. If different versions of ebtables can produce different results, then we need to either do a regexp comparison (which makes understanding the tests, and what may have gone wrong, more complicated, or keep multiple versions of the test results. But really if it's just our tests then that's not a big deal (and anyway, even if you change ebtables behavior to match iptables-ebtables, we will still have to account for both styles in our tests at least until RHEL7 is EOL (unless the RHEL7 ebtables package is updated), which is a *long time* away :-). The whole intent of filing this BZ in the first place was just to make sure everyone was aware of the change, and had thought about the possible consequences.)

Comment 8 Phil Sutter 2019-02-18 13:26:10 UTC
Hi Laine,

(In reply to Laine Stump from comment #7)
> I'm not advocating one way or the other, just wondering if you had forgotten
> about it, or if you purposefully intended to not change it. I'm fine with it
> either way.

My reason for sending a patch to legacy ebtables was to help decide if I should
adjust ebtables-nft to the non-conformant way of printing IPv6 prefixes. I didn't
do the same for MAC address formatting since the decision was clear there IMO.

> (Well, I really think variable-length MAC address strings are ugly, and it
> complicates our tests to have to deal with variable and fixed length
> MACs.(since the way the test works is 1) apply some abstract rule at a
> higher level (in this case libvirt's nwfilter rules), then 2) diff (i.e. a
> straight strcmp, not a regexp match) the output of various subsets of
> ebtables -L (and iptables -L and ip6tables -L) with output that was captured
> during a "known good" run. If different versions of ebtables can produce
> different results, then we need to either do a regexp comparison (which
> makes understanding the tests, and what may have gone wrong, more
> complicated, or keep multiple versions of the test results. But really if
> it's just our tests then that's not a big deal (and anyway, even if you
> change ebtables behavior to match iptables-ebtables, we will still have to
> account for both styles in our tests at least until RHEL7 is EOL (unless the
> RHEL7 ebtables package is updated), which is a *long time* away :-). The
> whole intent of filing this BZ in the first place was just to make sure
> everyone was aware of the change, and had thought about the possible
> consequences.)

I don't think changing ebtables output in RHEL7 is acceptable. But you're right,
this change should be documented.

Thanks, Phil


Note You need to log in before you can comment on or make changes to this bug.