11:08 a.m.
I found these when I ran the tck on RHEL8 beta.
Laine Stump (4):
storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
storage: fix/improve diagnostic messages
networks: remove stray use of brctl command
nwfilter: allow for ebtables *not* removing leading 0 from mac
addresses
scripts/networks/340-guest-network-bridge.t | 4 +-
scripts/nwfilter/100-ping-still-working.t | 4 +-
scripts/nwfilter/210-no-mac-spoofing.t | 4 +-
scripts/storage/100-create-vol-dir.t | 36 +++++++++-------
scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++---------
5 files changed, 54 insertions(+), 42 deletions(-)
--
2.20.1
11:08 a.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
RHEL8 has dropped support for qcow1 format images, so skip the tests
related to creating/cloning qcow1 images (based on the output of
qemu-img -help).
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
2 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/scripts/storage/100-create-vol-dir.t b/scripts/storage/100-create-vol-dir.t
index 952012c..6262d69 100644
--- a/scripts/storage/100-create-vol-dir.t
+++ b/scripts/storage/100-create-vol-dir.t
@@ -99,18 +99,24 @@ lives_ok(sub { $vol->delete(0) }, "deleted volume");
-ok_volume(sub { $vol = $pool->create_volume($volqcow1xml) }, "create qcow
volume");
+SKIP: {
+ if (`qemu-img -help` !~ "^Supported formats: .* qcow ") {
+ skip "qcow1 format not supported", 4;
+ }
-$path = xpath($vol, "string(/volume/target/path)");
-$st = stat($path);
+ ok_volume(sub { $vol = $pool->create_volume($volqcow1xml) }, "create qcow
volume");
-ok($st, "path $path exists");
+ $path = xpath($vol, "string(/volume/target/path)");
+ $st = stat($path);
-# Don't know exactly how large a qcow1 empty file is, but it
-# should be quite small :-)
-ok($st->size < 1024*1024, "basic qcow1 header is allocated");
+ ok($st, "path $path exists");
-lives_ok(sub { $vol->delete(0) }, "deleted volume");
+ # Don't know exactly how large a qcow1 empty file is, but it
+ # should be quite small :-)
+ ok($st->size < 1024*1024, "basic qcow1 header is allocated");
+
+ lives_ok(sub { $vol->delete(0) }, "deleted volume");
+}
diff --git a/scripts/storage/200-clone-vol-dir.t b/scripts/storage/200-clone-vol-dir.t
index cc0daba..787564f 100644
--- a/scripts/storage/200-clone-vol-dir.t
+++ b/scripts/storage/200-clone-vol-dir.t
@@ -106,39 +106,45 @@ diag "Now testing cloning of various formats";
my @formats = qw(raw qcow qcow2 vmdk vpc);
foreach my $format (@formats) {
- diag "Cloning source volume to $format format";
- my $volclonexml = $tck->generic_volume("tck$format", $format,
((1024*1024*50)+4096))->as_xml;
+ SKIP: {
+ if (($format eq "qcow") and (`qemu-img -help` !~ "^Supported
formats: .* qcow ")) {
+ skip "qcow1 format not supported", 9;
+ }
- my $clone;
- ok_volume(sub { $clone = $pool->clone_volume($volclonexml, $vol) }, "clone to
$format volume");
+ diag "Cloning source volume to $format format";
+ my $volclonexml = $tck->generic_volume("tck$format", $format,
((1024*1024*50)+4096))->as_xml;
- $path = xpath($clone, "string(/volume/target/path)");
- $st = stat($path);
- ok($st, "path $path exists");
- ok($st->size >= ((1024*1024*50)+4096), "size is at least 50M");
+ my $clone;
+ ok_volume(sub { $clone = $pool->clone_volume($volclonexml, $vol) },
"clone to $format volume");
+ $path = xpath($clone, "string(/volume/target/path)");
+ $st = stat($path);
+ ok($st, "path $path exists");
+ ok($st->size >= ((1024*1024*50)+4096), "size is at least 50M");
- diag "Cloning cloned volume back to raw format";
- my $voldstxml = $tck->generic_volume("tckdst", "raw",
((1024*1024*50)+4096))->as_xml;
- my $result;
- ok_volume(sub { $result = $pool->clone_volume($voldstxml, $clone) }, "clone
back to raw volume");
+ diag "Cloning cloned volume back to raw format";
+ my $voldstxml = $tck->generic_volume("tckdst", "raw",
((1024*1024*50)+4096))->as_xml;
+ my $result;
+ ok_volume(sub { $result = $pool->clone_volume($voldstxml, $clone) },
"clone back to raw volume");
- $path = xpath($result, "string(/volume/target/path)");
- $st = stat($path);
- ok($st, "path $path exists");
+ $path = xpath($result, "string(/volume/target/path)");
- is($st->size, ((1024*1024*50)+4096), "size is 50M");
+ $st = stat($path);
+ ok($st, "path $path exists");
- diag "Comparing data between source & result volume";
+ is($st->size, ((1024*1024*50)+4096), "size is 50M");
- my $dstdigest = &digest($path);
+ diag "Comparing data between source & result volume";
- is($srcdigest, $dstdigest, "digests match");
+ my $dstdigest = &digest($path);
- lives_ok(sub { $clone->delete(0) }, "deleted clone volume");
- lives_ok(sub { $result->delete(0) }, "deleted result volume");
+ is($srcdigest, $dstdigest, "digests match");
+
+ lives_ok(sub { $clone->delete(0) }, "deleted clone volume");
+ lives_ok(sub { $result->delete(0) }, "deleted result volume");
+ }
}
--
2.20.1
6:47 p.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote:
RHEL8 has dropped support for qcow1 format images, so skip the tests
related to creating/cloning qcow1 images (based on the output of
qemu-img -help).
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
2 files changed, 41 insertions(+), 29 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
This is an example where libvirt storage pool capabilities would be
useful.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:10 p.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
On Mon, Feb 11, 2019, 5:47 AM Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote:
> RHEL8 has dropped support for qcow1 format images, so skip the tests
> related to creating/cloning qcow1 images (based on the output of
> qemu-img -help).
>
> Signed-off-by: Laine Stump <laine(a)laine.org>
> ---
> scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
> scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
> 2 files changed, 41 insertions(+), 29 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
This is an example where libvirt storage pool capabilities would be
useful.
Yeah, or maybe listing the supported types in the device capabilities for
the disks. I had meant to point that out but forgot.
7:12 p.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
On Mon, Feb 11, 2019 at 06:10:38AM -0500, Laine Stump wrote:
On Mon, Feb 11, 2019, 5:47 AM Daniel P. Berrangé
<berrange(a)redhat.com>
wrote:
> On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote:
> > RHEL8 has dropped support for qcow1 format images, so skip the tests
> > related to creating/cloning qcow1 images (based on the output of
> > qemu-img -help).
> >
> > Signed-off-by: Laine Stump <laine(a)laine.org>
> > ---
> > scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
> > scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
> > 2 files changed, 41 insertions(+), 29 deletions(-)
>
> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
>
>
> This is an example where libvirt storage pool capabilities would be
> useful.
>
Yeah, or maybe listing the supported types in the device capabilities for
the disks. I had meant to point that out but forgot.
We would need both, because QEMU has a setup where qemu-img can support a
disk format while qemu-system-XXX will not support it. This is so that
we can limit what is usable at runtime, but still have qemu-img for data
liberation from old format images.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
8:14 p.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
On 2/11/19 6:12 AM, Daniel P. Berrangé wrote:
On Mon, Feb 11, 2019 at 06:10:38AM -0500, Laine Stump wrote:
> On Mon, Feb 11, 2019, 5:47 AM Daniel P. Berrangé <berrange(a)redhat.com>
> wrote:
>
>> On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote:
>>> RHEL8 has dropped support for qcow1 format images, so skip the tests
>>> related to creating/cloning qcow1 images (based on the output of
>>> qemu-img -help).
>>>
>>> Signed-off-by: Laine Stump <laine(a)laine.org>
>>> ---
>>> scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
>>> scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
>>> 2 files changed, 41 insertions(+), 29 deletions(-)
>>
>> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
>>
>>
>> This is an example where libvirt storage pool capabilities would be
>> useful.
>>
Current working code I have (unreviewed) has:
<storagepoolCapabilities>
...
<pool type='fs' supported='yes'>
<poolOptions>
<defaultFormat type='auto'/>
<enum name='sourceFormatType'>
<value>auto</value>
<value>ext2</value>
<value>ext3</value>
<value>ext4</value>
<value>ufs</value>
<value>iso9660</value>
<value>udf</value>
<value>gfs</value>
<value>gfs2</value>
<value>vfat</value>
<value>hfs+</value>
<value>xfs</value>
<value>ocfs2</value>
</enum>
<enum name='requiredSourceElements'>
<value>device</value>
</enum>
</poolOptions>
<volOptions>
<defaultFormat type='raw'/>
<enum name='targetFormatType'>
<value>none</value>
<value>raw</value>
<value>dir</value>
<value>bochs</value>
<value>cloop</value>
<value>dmg</value>
<value>iso</value>
<value>vpc</value>
<value>vdi</value>
<value>fat</value>
<value>vhd</value>
<value>ploop</value>
<value>cow</value>
<value>qcow</value>
<value>qcow2</value>
<value>qed</value>
<value>vmdk</value>
</enum>
</volOptions>
</pool>
...
</storagepoolCapabilities>
>
> Yeah, or maybe listing the supported types in the device capabilities for
> the disks. I had meant to point that out but forgot.
We would need both, because QEMU has a setup where qemu-img can support a
disk format while qemu-system-XXX will not support it. This is so that
we can limit what is usable at runtime, but still have qemu-img for data
liberation from old format images.
Regards,
Daniel
So, would this be something formatted from src/util/virstoragefile.c
FileTypeInfo for a specific $path then? Or more generically from
qemu-img like I assume this patch does? IIRC -help scraping has been
removed and the "hope" was some day some sort of capabilities type
approach would be used. Been a while since I've thought about it though.
John
9:03 p.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
On Mon, Feb 11, 2019 at 07:14:26AM -0500, John Ferlan wrote:
On 2/11/19 6:12 AM, Daniel P. Berrangé wrote:
> On Mon, Feb 11, 2019 at 06:10:38AM -0500, Laine Stump wrote:
>> On Mon, Feb 11, 2019, 5:47 AM Daniel P. Berrangé <berrange(a)redhat.com>
>> wrote:
>>
>>> On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote:
>>>> RHEL8 has dropped support for qcow1 format images, so skip the tests
>>>> related to creating/cloning qcow1 images (based on the output of
>>>> qemu-img -help).
>>>>
>>>> Signed-off-by: Laine Stump <laine(a)laine.org>
>>>> ---
>>>> scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
>>>> scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
>>>> 2 files changed, 41 insertions(+), 29 deletions(-)
>>>
>>> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
>>>
>>>
>>> This is an example where libvirt storage pool capabilities would be
>>> useful.
>>>
Current working code I have (unreviewed) has:
<storagepoolCapabilities>
...
<pool type='fs' supported='yes'>
<poolOptions>
<defaultFormat type='auto'/>
<enum name='sourceFormatType'>
<value>auto</value>
<value>ext2</value>
<value>ext3</value>
<value>ext4</value>
<value>ufs</value>
<value>iso9660</value>
<value>udf</value>
<value>gfs</value>
<value>gfs2</value>
<value>vfat</value>
<value>hfs+</value>
<value>xfs</value>
<value>ocfs2</value>
</enum>
<enum name='requiredSourceElements'>
<value>device</value>
</enum>
</poolOptions>
<volOptions>
<defaultFormat type='raw'/>
<enum name='targetFormatType'>
<value>none</value>
<value>raw</value>
<value>dir</value>
<value>bochs</value>
<value>cloop</value>
<value>dmg</value>
<value>iso</value>
<value>vpc</value>
<value>vdi</value>
<value>fat</value>
<value>vhd</value>
<value>ploop</value>
<value>cow</value>
<value>qcow</value>
<value>qcow2</value>
<value>qed</value>
<value>vmdk</value>
</enum>
</volOptions>
</pool>
...
</storagepoolCapabilities>
>>
>> Yeah, or maybe listing the supported types in the device capabilities for
>> the disks. I had meant to point that out but forgot.
>
> We would need both, because QEMU has a setup where qemu-img can support a
> disk format while qemu-system-XXX will not support it. This is so that
> we can limit what is usable at runtime, but still have qemu-img for data
> liberation from old format images.
So, would this be something formatted from src/util/virstoragefile.c
FileTypeInfo for a specific $path then? Or more generically from
qemu-img like I assume this patch does? IIRC -help scraping has been
removed and the "hope" was some day some sort of capabilities type
approach would be used. Been a while since I've thought about it though.
I meant that the "dom capabilities" XML needs to report supported
block driver formats separately from "storage capabilities". This
isn't related to specific disk image paths, it is a property of
the QEMU binaries.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
10:46 p.m.
New subject: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
On 2/11/19 6:12 AM, Daniel P. Berrangé wrote:
On Mon, Feb 11, 2019 at 06:10:38AM -0500, Laine Stump wrote:
> On Mon, Feb 11, 2019, 5:47 AM Daniel P. Berrangé <berrange(a)redhat.com>
> wrote:
>
>> On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote:
>>> RHEL8 has dropped support for qcow1 format images, so skip the tests
>>> related to creating/cloning qcow1 images (based on the output of
>>> qemu-img -help).
>>>
>>> Signed-off-by: Laine Stump <laine(a)laine.org>
>>> ---
>>> scripts/storage/100-create-vol-dir.t | 22 ++++++++-----
>>> scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------
>>> 2 files changed, 41 insertions(+), 29 deletions(-)
>> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
>>
>>
>> This is an example where libvirt storage pool capabilities would be
>> useful.
>>
> Yeah, or maybe listing the supported types in the device capabilities for
> the disks. I had meant to point that out but forgot.
We would need both, because QEMU has a setup where qemu-img can support a
disk format while qemu-system-XXX will not support it. This is so that
we can limit what is usable at runtime, but still have qemu-img for data
liberation from old format images.
Now that you mention that, I'm surprised that's not the case with RHEL8
and qcow1 - qemu-img doesn't support it. Maybe they got a bit
over-zealous when deprecating/removing qcow1 support.
11:08 a.m.
New subject: [libvirt] [tck PATCH 2/4] storage: fix/improve diagnostic messages
Due to copy/paste, the tests for several other formats were described
as "qcow". Also, a couple of messages didn't give the image format.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/storage/100-create-vol-dir.t | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/scripts/storage/100-create-vol-dir.t b/scripts/storage/100-create-vol-dir.t
index 6262d69..9663d28 100644
--- a/scripts/storage/100-create-vol-dir.t
+++ b/scripts/storage/100-create-vol-dir.t
@@ -94,7 +94,7 @@ is($st->size, 1024*1024*50, "size is 50M");
# overhead for a file
ok($st->blocks >= (1024*1024*50/512), "alot of blocks allocated");
-lives_ok(sub { $vol->delete(0) }, "deleted volume");
+lives_ok(sub { $vol->delete(0) }, "deleted raw volume");
@@ -104,7 +104,7 @@ SKIP: {
skip "qcow1 format not supported", 4;
}
- ok_volume(sub { $vol = $pool->create_volume($volqcow1xml) }, "create qcow
volume");
+ ok_volume(sub { $vol = $pool->create_volume($volqcow1xml) }, "create qcow1
volume");
$path = xpath($vol, "string(/volume/target/path)");
$st = stat($path);
@@ -121,7 +121,7 @@ SKIP: {
-ok_volume(sub { $vol = $pool->create_volume($volqcow2xml) }, "create qcow
volume");
+ok_volume(sub { $vol = $pool->create_volume($volqcow2xml) }, "create qcow2
volume");
$path = xpath($vol, "string(/volume/target/path)");
$st = stat($path);
@@ -132,12 +132,12 @@ ok($st, "path $path exists");
# should be quite small :-)
ok($st->size < 1024*1024, "basic qcow2 header is allocated");
-lives_ok(sub { $vol->delete(0) }, "deleted volume");
+lives_ok(sub { $vol->delete(0) }, "deleted qcow2 volume");
-ok_volume(sub { $vol = $pool->create_volume($volvmdkxml) }, "create qcow
volume");
+ok_volume(sub { $vol = $pool->create_volume($volvmdkxml) }, "create vmdk
volume");
$path = xpath($vol, "string(/volume/target/path)");
$st = stat($path);
@@ -148,12 +148,12 @@ ok($st, "path $path exists");
# should be quite small :-)
ok($st->size < 1024*1024, "basic vmdk header is allocated");
-lives_ok(sub { $vol->delete(0) }, "deleted volume");
+lives_ok(sub { $vol->delete(0) }, "deleted vmdk volume");
-ok_volume(sub { $vol = $pool->create_volume($volvpcxml) }, "create qcow
volume");
+ok_volume(sub { $vol = $pool->create_volume($volvpcxml) }, "create vpc
volume");
$path = xpath($vol, "string(/volume/target/path)");
$st = stat($path);
@@ -164,5 +164,5 @@ ok($st, "path $path exists");
# should be quite small :-)
ok($st->size < 1024*1024, "basic vpc header is allocated");
-lives_ok(sub { $vol->delete(0) }, "deleted volume");
+lives_ok(sub { $vol->delete(0) }, "deleted vpc volume");
--
2.20.1
6:47 p.m.
New subject: [libvirt] [tck PATCH 2/4] storage: fix/improve diagnostic messages
On Thu, Feb 07, 2019 at 10:08:29PM -0500, Laine Stump wrote:
Due to copy/paste, the tests for several other formats were
described
as "qcow". Also, a couple of messages didn't give the image format.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/storage/100-create-vol-dir.t | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:08 a.m.
New subject: [libvirt] [tck PATCH 3/4] networks: remove stray use of brctl command
brctl has been deprecated for a long time, and distros are starting to
remove it. "ip link blah type bridge" should be used instead.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/networks/340-guest-network-bridge.t | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/networks/340-guest-network-bridge.t
b/scripts/networks/340-guest-network-bridge.t
index e5db0ff..498bcb6 100644
--- a/scripts/networks/340-guest-network-bridge.t
+++ b/scripts/networks/340-guest-network-bridge.t
@@ -36,9 +36,9 @@ my $conn = eval { $tck->setup(); };
BAIL_OUT "failed to setup test harness: $@" if $@;
END { $tck->cleanup if $tck; }
-((system "brctl addbr tck") == 0) or die "cannot create bridge
'tck'";
+((system "ip link add name tck type bridge") == 0) or die "cannot create
bridge 'tck'";
-END { system "brctl delbr tck" }
+END { system "ip link del tck" }
my $b = Sys::Virt::TCK::NetworkBuilder->new(name => "tck");
$b->bridge("tck");
--
2.20.1
6:48 p.m.
New subject: [libvirt] [tck PATCH 3/4] networks: remove stray use of brctl command
On Thu, Feb 07, 2019 at 10:08:30PM -0500, Laine Stump wrote:
brctl has been deprecated for a long time, and distros are starting
to
remove it. "ip link blah type bridge" should be used instead.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/networks/340-guest-network-bridge.t | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:08 a.m.
New subject: [libvirt] [tck PATCH 4/4] nwfilter: allow for ebtables *not* removing leading 0 from mac addresses
The ebtables command in RHEL8 prints 00 in a MAC address as.... "00",
unlike e.g. Fedora 29, which prints it as "0". Allow for both.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/nwfilter/100-ping-still-working.t | 4 ++--
scripts/nwfilter/210-no-mac-spoofing.t | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/nwfilter/100-ping-still-working.t
b/scripts/nwfilter/100-ping-still-working.t
index a88eb02..656722d 100644
--- a/scripts/nwfilter/100-ping-still-working.t
+++ b/scripts/nwfilter/100-ping-still-working.t
@@ -76,9 +76,9 @@ diag "ip is $guestip";
my $ebtables = (-e '/sbin/ebtables') ? '/sbin/ebtables' :
'/usr/sbin/ebtables';
my $ebtable = `$ebtables -L;$ebtables -t nat -L`;
diag $ebtable;
-# ebtables shortens :00: to :0: so we need to do that too
+# ebtables *might* shorten :00: to :0: so we need to allow for both when searching
$_ = $mac;
-s/00/0/g;
+s/0([0-9])/0{0,1}$1/g;
ok($ebtable =~ $_, "check ebtables entry");
# ping guest1
diff --git a/scripts/nwfilter/210-no-mac-spoofing.t
b/scripts/nwfilter/210-no-mac-spoofing.t
index 78c500c..95f003a 100644
--- a/scripts/nwfilter/210-no-mac-spoofing.t
+++ b/scripts/nwfilter/210-no-mac-spoofing.t
@@ -81,9 +81,9 @@ diag "guest ip is $guestip";
my $ebtables = (-e '/sbin/ebtables') ? '/sbin/ebtables' :
'/usr/sbin/ebtables';
my $ebtable = `$ebtables -L;$ebtables -t nat -L`;
diag $ebtable;
-# ebtables shortens :00: to :0: so we need to do that too
+# ebtables *might* shorten :00: to :0: so we need to allow for both when searching
$_ = $mac;
-s/00/0/g;
+s/0([0-9])/0{0,1}$1/g;
ok($ebtable =~ $_, "check ebtables entry");
my $macfalse = "52:54:00:f9:21:22";
--
2.20.1
6:48 p.m.
New subject: [libvirt] [tck PATCH 4/4] nwfilter: allow for ebtables *not* removing leading 0 from mac addresses
On Thu, Feb 07, 2019 at 10:08:31PM -0500, Laine Stump wrote:
The ebtables command in RHEL8 prints 00 in a MAC address as....
"00",
unlike e.g. Fedora 29, which prints it as "0". Allow for both.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
scripts/nwfilter/100-ping-still-working.t | 4 ++--
scripts/nwfilter/210-no-mac-spoofing.t | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:03 a.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
Since this test (050-apply-verify-host.t), we can't use a regexp in
the string to be compared. The fix method that leads to the least
changes is to use sed to remove potential leading 0's.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
(These changes fix *almost* all failures in
nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
might be legitimate problems with ebtables and IPv6)
scripts/nwfilter/nwfilter2vmtest.sh | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall | 4 ++--
scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall | 4 ++--
9 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/scripts/nwfilter/nwfilter2vmtest.sh b/scripts/nwfilter/nwfilter2vmtest.sh
index 778013b..2e8c0b0 100644
--- a/scripts/nwfilter/nwfilter2vmtest.sh
+++ b/scripts/nwfilter/nwfilter2vmtest.sh
@@ -653,7 +653,7 @@ main() {
exit 1
fi
- createVM "${vm2}" "${TESTFILTERNAME}" "10.1.1.1"
"52:54:0:9f:33:da" \
+ createVM "${vm2}" "${TESTFILTERNAME}" "10.1.1.1"
"52:54:10:9f:33:da" \
"${flags}"
if [ $? -ne 0 ]; then
echo "Could not create VM ${vm2}. Exiting."
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
index 34174a0..a3c04df 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
@@ -1,4 +1,4 @@
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | grep -v "^Bridge" | grep -v "^$"
-p ARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype 12 --arp-ptype
0x22 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f -j ACCEPT
-p ARP -s 1:2:3:4:5:6 --arp-op Request --arp-htype 255 --arp-ptype 0xff -j ACCEPT
-p ARP -s 1:2:3:4:5:6 --arp-op 11 --arp-htype 256 --arp-ptype 0x100 -j ACCEPT
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
index 83441c2..6933a15 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
@@ -2,7 +2,7 @@
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p IPv4 -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --ip-src 10.1.2.3 --ip-dst 10.1.2.3
--ip-proto udp --ip-sport 20:22 --ip-dport 100:101 -j ACCEPT
-p IPv4 --ip-src 10.1.0.0/17 --ip-dst 10.1.2.0/24 --ip-tos 0x3F --ip-proto udp -j ACCEPT
#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v
"^$"
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
index bb00629..7ecace2 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
@@ -2,7 +2,7 @@
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v "^Bridge" | grep -v
"^$"
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p ARP -s 1:2:3:4:5:6 -j ACCEPT
#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v
"^$"
-p IPv4 -d aa:bb:cc:dd:ee:ff -j ACCEPT
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
index e0d9c8c..7dd98e5 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
@@ -1,4 +1,4 @@
-#ebtables -t nat -L libvirt-I-vnet0 | sed s/0x8035/RARP/g | grep -v "^Bridge" |
grep -v "^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | sed s/0x8035/RARP/g | grep -v "^Bridge" |
grep -v "^$"
-p RARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype 12 --arp-ptype
0x22 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f -j ACCEPT
-p RARP -s 1:2:3:4:5:6 --arp-op Request --arp-htype 255 --arp-ptype 0xff -j ACCEPT
-p RARP -s 1:2:3:4:5:6 --arp-op 11 --arp-htype 256 --arp-ptype 0x100 -j ACCEPT
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
index 5ee2545..b95ea26 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
@@ -6,9 +6,9 @@
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L I-vnet0-stp-xyz | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L I-vnet0-stp-xyz | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/06:05:04:03:02:01/6:5:4:3:2:1/g | grep -v "^Bridge" | grep -v "^$"
-s 1:2:3:4:5:6 -d BGA --stp-root-prio 4660:9029 --stp-root-addr 6:5:4:3:2:1
--stp-root-cost 287454020:573785173 -j RETURN
-#ebtables -t nat -L O-vnet0-stp-xyz | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L O-vnet0-stp-xyz | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/06:05:04:03:02:01/6:5:4:3:2:1/g | grep -v "^Bridge" | grep -v "^$"
-s 1:2:3:4:5:6 -d BGA --stp-type 18 --stp-flags 68 -j CONTINUE
-s 1:2:3:4:5:6 -d BGA --stp-sender-prio 4660 --stp-sender-addr 6:5:4:3:2:1 --stp-port
123:234 --stp-msg-age 5544:5555 --stp-max-age 7777:8888 --stp-hello-time 12345:12346
--stp-forward-delay 54321:65432 -j DROP
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
index 849e364..8d1cf76 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
@@ -50,7 +50,7 @@ FO-vnet0 all -- 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-out
vnet0 --p
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v "^Bridge" | grep -v
"^$"
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p ARP -s 1:2:3:4:5:6 -j ACCEPT
-p ARP -s 1:2:3:4:5:6 -j DROP
-p ARP -s 1:2:3:4:5:6 -j DROP
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
b/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
index 1b5f3ce..499ed5b 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
+++ b/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
@@ -24,7 +24,7 @@
#ebtables -t nat -L O-vnet0-ipv4 | grep -v "^Bridge" | grep -v "^$"
-j ACCEPT
#ebtables -t nat -L I-vnet0-arp-mac | grep -v "^Bridge" | grep -v
"^$"
--p ARP --arp-mac-src 52:54:0:9f:33:da -j RETURN
+-p ARP --arp-mac-src 52:54:10:9f:33:da -j RETURN
-j DROP
#ebtables -t nat -L I-vnet0-arp-ip | grep -v "^Bridge" | grep -v
"^$"
-p ARP --arp-ip-src 10.1.1.1 -j RETURN
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
index a2fbfd3..4a08381 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
@@ -1,9 +1,9 @@
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p 802_1Q -s aa:bb:cc:dd:ee:ff -d 1:2:3:4:5:6 --vlan-id 291 -j CONTINUE
-p 802_1Q -s aa:bb:cc:dd:ee:ff -d 1:2:3:4:5:6 --vlan-id 1234 -j RETURN
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-encap 2054 -j DROP
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-encap 4660 -j ACCEPT
-#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-O-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-id 291 -j CONTINUE
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-id 1234 -j RETURN
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-id 291 -j DROP
--
2.20.1
6:50 p.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
Since this test (050-apply-verify-host.t), we can't use a regexp
in
the string to be compared. The fix method that leads to the least
changes is to use sed to remove potential leading 0's.
Signed-off-by: Laine Stump <laine(a)laine.org>
---
(These changes fix *almost* all failures in
nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
might be legitimate problems with ebtables and IPv6)
Interesting, I swear I have previously got that test to succeed so
wonder what's changed since then !
scripts/nwfilter/nwfilter2vmtest.sh | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall | 4 ++--
scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat | 2 +-
scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall | 4 ++--
9 files changed, 11 insertions(+), 11 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
diff --git a/scripts/nwfilter/nwfilter2vmtest.sh b/scripts/nwfilter/nwfilter2vmtest.sh
index 778013b..2e8c0b0 100644
--- a/scripts/nwfilter/nwfilter2vmtest.sh
+++ b/scripts/nwfilter/nwfilter2vmtest.sh
@@ -653,7 +653,7 @@ main() {
exit 1
fi
- createVM "${vm2}" "${TESTFILTERNAME}" "10.1.1.1"
"52:54:0:9f:33:da" \
+ createVM "${vm2}" "${TESTFILTERNAME}" "10.1.1.1"
"52:54:10:9f:33:da" \
"${flags}"
if [ $? -ne 0 ]; then
echo "Could not create VM ${vm2}. Exiting."
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
index 34174a0..a3c04df 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/arp-test.fwall
@@ -1,4 +1,4 @@
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | grep -v "^Bridge" | grep -v "^$"
-p ARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype 12 --arp-ptype
0x22 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f -j ACCEPT
-p ARP -s 1:2:3:4:5:6 --arp-op Request --arp-htype 255 --arp-ptype 0xff -j ACCEPT
-p ARP -s 1:2:3:4:5:6 --arp-op 11 --arp-htype 256 --arp-ptype 0x100 -j ACCEPT
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
index 83441c2..6933a15 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/ip-test.fwall
@@ -2,7 +2,7 @@
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p IPv4 -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --ip-src 10.1.2.3 --ip-dst 10.1.2.3
--ip-proto udp --ip-sport 20:22 --ip-dport 100:101 -j ACCEPT
-p IPv4 --ip-src 10.1.0.0/17 --ip-dst 10.1.2.0/24 --ip-tos 0x3F --ip-proto udp -j ACCEPT
#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v
"^$"
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
index bb00629..7ecace2 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/mac-test.fwall
@@ -2,7 +2,7 @@
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v "^Bridge" | grep -v
"^$"
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p ARP -s 1:2:3:4:5:6 -j ACCEPT
#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v
"^$"
-p IPv4 -d aa:bb:cc:dd:ee:ff -j ACCEPT
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
index e0d9c8c..7dd98e5 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/rarp-test.fwall
@@ -1,4 +1,4 @@
-#ebtables -t nat -L libvirt-I-vnet0 | sed s/0x8035/RARP/g | grep -v "^Bridge"
| grep -v "^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/0a:0b:0c:0d:0e:0f/a:b:c:d:e:f/g | sed s/0x8035/RARP/g | grep -v "^Bridge" |
grep -v "^$"
-p RARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype 12 --arp-ptype
0x22 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f -j ACCEPT
-p RARP -s 1:2:3:4:5:6 --arp-op Request --arp-htype 255 --arp-ptype 0xff -j ACCEPT
-p RARP -s 1:2:3:4:5:6 --arp-op 11 --arp-htype 256 --arp-ptype 0x100 -j ACCEPT
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
index 5ee2545..b95ea26 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/stp-test.fwall
@@ -6,9 +6,9 @@
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L I-vnet0-stp-xyz | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L I-vnet0-stp-xyz | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/06:05:04:03:02:01/6:5:4:3:2:1/g | grep -v "^Bridge" | grep -v "^$"
-s 1:2:3:4:5:6 -d BGA --stp-root-prio 4660:9029 --stp-root-addr 6:5:4:3:2:1
--stp-root-cost 287454020:573785173 -j RETURN
-#ebtables -t nat -L O-vnet0-stp-xyz | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L O-vnet0-stp-xyz | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | sed
s/06:05:04:03:02:01/6:5:4:3:2:1/g | grep -v "^Bridge" | grep -v "^$"
-s 1:2:3:4:5:6 -d BGA --stp-type 18 --stp-flags 68 -j CONTINUE
-s 1:2:3:4:5:6 -d BGA --stp-sender-prio 4660 --stp-sender-addr 6:5:4:3:2:1 --stp-port
123:234 --stp-msg-age 5544:5555 --stp-max-age 7777:8888 --stp-hello-time 12345:12346
--stp-forward-delay 54321:65432 -j DROP
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
index 849e364..8d1cf76 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/target-test.fwall
@@ -50,7 +50,7 @@ FO-vnet0 all -- 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-out
vnet0 --p
-i vnet0 -j libvirt-I-vnet0
#ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v "^Bridge" | grep -v
"^$"
-o vnet0 -j libvirt-O-vnet0
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p ARP -s 1:2:3:4:5:6 -j ACCEPT
-p ARP -s 1:2:3:4:5:6 -j DROP
-p ARP -s 1:2:3:4:5:6 -j DROP
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
b/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
index 1b5f3ce..499ed5b 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
+++ b/scripts/nwfilter/nwfilterxml2fwallout/testvm.fwall.dat
@@ -24,7 +24,7 @@
#ebtables -t nat -L O-vnet0-ipv4 | grep -v "^Bridge" | grep -v "^$"
-j ACCEPT
#ebtables -t nat -L I-vnet0-arp-mac | grep -v "^Bridge" | grep -v
"^$"
--p ARP --arp-mac-src 52:54:0:9f:33:da -j RETURN
+-p ARP --arp-mac-src 52:54:10:9f:33:da -j RETURN
-j DROP
#ebtables -t nat -L I-vnet0-arp-ip | grep -v "^Bridge" | grep -v
"^$"
-p ARP --arp-ip-src 10.1.1.1 -j RETURN
diff --git a/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
b/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
index a2fbfd3..4a08381 100644
--- a/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
+++ b/scripts/nwfilter/nwfilterxml2fwallout/vlan-test.fwall
@@ -1,9 +1,9 @@
-#ebtables -t nat -L libvirt-I-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-I-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p 802_1Q -s aa:bb:cc:dd:ee:ff -d 1:2:3:4:5:6 --vlan-id 291 -j CONTINUE
-p 802_1Q -s aa:bb:cc:dd:ee:ff -d 1:2:3:4:5:6 --vlan-id 1234 -j RETURN
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-encap 2054 -j DROP
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-encap 4660 -j ACCEPT
-#ebtables -t nat -L libvirt-O-vnet0 | grep -v "^Bridge" | grep -v
"^$"
+#ebtables -t nat -L libvirt-O-vnet0 | sed s/01:02:03:04:05:06/1:2:3:4:5:6/g | grep -v
"^Bridge" | grep -v "^$"
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-id 291 -j CONTINUE
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-id 1234 -j RETURN
-p 802_1Q -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --vlan-id 291 -j DROP
--
2.20.1
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:07 p.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
> Since this test (050-apply-verify-host.t), we can't use a regexp in
> the string to be compared. The fix method that leads to the least
> changes is to use sed to remove potential leading 0's.
>
> Signed-off-by: Laine Stump <laine(a)laine.org>
> ---
>
> (These changes fix *almost* all failures in
> nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
> might be legitimate problems with ebtables and IPv6)
Interesting, I swear I have previously got that test to succeed so
wonder what's changed since then !
I figured it out yesterday evening but haven't gotten a chance to post it
yet. I was being alarmist - its not a behavioral difference, but just a
difference in how ipv6 addresses are formatted. The original ebtables
reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::) while
the iptables-ebtables package that RHRL8 is now using reports it with a
prefix (/65). They probably hadn't switched packages yet the last time you
ran the test. I have a patch that modifies the expected output (and uses
sed to modify the output from 'older' hosts, similar to what you had done
for RARP vs 0x8035) and will post it in a few hours, once I've had coffee
and tested on both types of host.
7:11 p.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On Mon, Feb 11, 2019 at 06:07:40AM -0500, Laine Stump wrote:
On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé
<berrange(a)redhat.com>
wrote:
> On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
> > Since this test (050-apply-verify-host.t), we can't use a regexp in
> > the string to be compared. The fix method that leads to the least
> > changes is to use sed to remove potential leading 0's.
> >
> > Signed-off-by: Laine Stump <laine(a)laine.org>
> > ---
> >
> > (These changes fix *almost* all failures in
> > nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
> > might be legitimate problems with ebtables and IPv6)
>
> Interesting, I swear I have previously got that test to succeed so
> wonder what's changed since then !
>
I figured it out yesterday evening but haven't gotten a chance to post it
yet. I was being alarmist - its not a behavioral difference, but just a
difference in how ipv6 addresses are formatted. The original ebtables
reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::) while
the iptables-ebtables package that RHRL8 is now using reports it with a
prefix (/65). They probably hadn't switched packages yet the last time you
ran the test. I have a patch that modifies the expected output (and uses
sed to modify the output from 'older' hosts, similar to what you had done
for RARP vs 0x8035) and will post it in a few hours, once I've had coffee
and tested on both types of host.
IMHO that should be reported as a bug against ebtables. The output format
of the new tools should be 100% identical tothe old tools. Changing from
a netmask to a prefix is a significant semantic difference that will break
too many uses.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
10:51 p.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On 2/11/19 6:11 AM, Daniel P. Berrangé wrote:
On Mon, Feb 11, 2019 at 06:07:40AM -0500, Laine Stump wrote:
> On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé <berrange(a)redhat.com>
> wrote:
>
>> On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
>>> Since this test (050-apply-verify-host.t), we can't use a regexp in
>>> the string to be compared. The fix method that leads to the least
>>> changes is to use sed to remove potential leading 0's.
>>>
>>> Signed-off-by: Laine Stump <laine(a)laine.org>
>>> ---
>>>
>>> (These changes fix *almost* all failures in
>>> nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
>>> might be legitimate problems with ebtables and IPv6)
>> Interesting, I swear I have previously got that test to succeed so
>> wonder what's changed since then !
>>
> I figured it out yesterday evening but haven't gotten a chance to post it
> yet. I was being alarmist - its not a behavioral difference, but just a
> difference in how ipv6 addresses are formatted. The original ebtables
> reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::) while
> the iptables-ebtables package that RHRL8 is now using reports it with a
> prefix (/65). They probably hadn't switched packages yet the last time you
> ran the test. I have a patch that modifies the expected output (and uses
> sed to modify the output from 'older' hosts, similar to what you had done
> for RARP vs 0x8035) and will post it in a few hours, once I've had coffee
> and tested on both types of host.
IMHO that should be reported as a bug against ebtables. The output format
of the new tools should be 100% identical tothe old tools. Changing from
a netmask to a prefix is a significant semantic difference that will break
too many uses.
I thought about that, but wasn't feeling that ambitious since it was
Sunday. If this is considered a bug, then changing the MAC address
format from %x:%x:%x:%x:%x:%x to %0x:%0x:%0x:%0x:%0x:%0x should also be
considered a bug.
I'll still post a patch to remedy it in the tests, but won't push it
(unless you think that's worthwhile) and will file a bug instead.
10:56 p.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On Mon, Feb 11, 2019 at 09:51:09AM -0500, Laine Stump wrote:
On 2/11/19 6:11 AM, Daniel P. Berrangé wrote:
> On Mon, Feb 11, 2019 at 06:07:40AM -0500, Laine Stump wrote:
> > On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé <berrange(a)redhat.com>
> > wrote:
> >
> > > On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
> > > > Since this test (050-apply-verify-host.t), we can't use a regexp
in
> > > > the string to be compared. The fix method that leads to the least
> > > > changes is to use sed to remove potential leading 0's.
> > > >
> > > > Signed-off-by: Laine Stump <laine(a)laine.org>
> > > > ---
> > > >
> > > > (These changes fix *almost* all failures in
> > > > nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
> > > > might be legitimate problems with ebtables and IPv6)
> > > Interesting, I swear I have previously got that test to succeed so
> > > wonder what's changed since then !
> > >
> > I figured it out yesterday evening but haven't gotten a chance to post it
> > yet. I was being alarmist - its not a behavioral difference, but just a
> > difference in how ipv6 addresses are formatted. The original ebtables
> > reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::) while
> > the iptables-ebtables package that RHRL8 is now using reports it with a
> > prefix (/65). They probably hadn't switched packages yet the last time you
> > ran the test. I have a patch that modifies the expected output (and uses
> > sed to modify the output from 'older' hosts, similar to what you had
done
> > for RARP vs 0x8035) and will post it in a few hours, once I've had coffee
> > and tested on both types of host.
> IMHO that should be reported as a bug against ebtables. The output format
> of the new tools should be 100% identical tothe old tools. Changing from
> a netmask to a prefix is a significant semantic difference that will break
> too many uses.
I thought about that, but wasn't feeling that ambitious since it was Sunday.
If this is considered a bug, then changing the MAC address format from
%x:%x:%x:%x:%x:%x to %0x:%0x:%0x:%0x:%0x:%0x should also be considered a
bug.
Yes, I thought about that too. I think it would be worth raising that with
the maintainers to validate this was intentional. I get the feeling they'll
say that the old behaviour was a clear bug. If anything I'd probably ask
them to fix the old impl to not skip leading zeros too. IMHO mac addrs
should always be exactly the same length when printed.
I'll still post a patch to remedy it in the tests, but won't
push it (unless
you think that's worthwhile) and will file a bug instead.
Yep, lets at least wait & see what response we get to a bug report on this
issue.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:04 a.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On 2/11/19 9:56 AM, Daniel P. Berrangé wrote:
On Mon, Feb 11, 2019 at 09:51:09AM -0500, Laine Stump wrote:
> On 2/11/19 6:11 AM, Daniel P. Berrangé wrote:
>> On Mon, Feb 11, 2019 at 06:07:40AM -0500, Laine Stump wrote:
>>> On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé <berrange(a)redhat.com>
>>> wrote:
>>>
>>>> On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
>>>>> Since this test (050-apply-verify-host.t), we can't use a regexp
in
>>>>> the string to be compared. The fix method that leads to the least
>>>>> changes is to use sed to remove potential leading 0's.
>>>>>
>>>>> Signed-off-by: Laine Stump <laine(a)laine.org>
>>>>> ---
>>>>>
>>>>> (These changes fix *almost* all failures in
>>>>> nwfilter/050-apply-verify-host.t on RHEL8. The rest look like they
>>>>> might be legitimate problems with ebtables and IPv6)
>>>> Interesting, I swear I have previously got that test to succeed so
>>>> wonder what's changed since then !
>>>>
>>> I figured it out yesterday evening but haven't gotten a chance to post
it
>>> yet. I was being alarmist - its not a behavioral difference, but just a
>>> difference in how ipv6 addresses are formatted. The original ebtables
>>> reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::) while
>>> the iptables-ebtables package that RHRL8 is now using reports it with a
>>> prefix (/65). They probably hadn't switched packages yet the last time
you
>>> ran the test. I have a patch that modifies the expected output (and uses
>>> sed to modify the output from 'older' hosts, similar to what you had
done
>>> for RARP vs 0x8035) and will post it in a few hours, once I've had
coffee
>>> and tested on both types of host.
>> IMHO that should be reported as a bug against ebtables. The output format
>> of the new tools should be 100% identical tothe old tools. Changing from
>> a netmask to a prefix is a significant semantic difference that will break
>> too many uses.
>
> I thought about that, but wasn't feeling that ambitious since it was Sunday.
> If this is considered a bug, then changing the MAC address format from
> %x:%x:%x:%x:%x:%x to %0x:%0x:%0x:%0x:%0x:%0x should also be considered a
> bug.
Yes, I thought about that too. I think it would be worth raising that with
the maintainers to validate this was intentional. I get the feeling they'll
say that the old behaviour was a clear bug. If anything I'd probably ask
them to fix the old impl to not skip leading zeros too. IMHO mac addrs
should always be exactly the same length when printed.
Yeah, that was another of the things that caused my ambivalence in
reporting it as a bug - I also think MAC addresses should be fixed
length (and I think that using netmasks for IPv6 is an exercise in
incoherence - a prefix is much easier to consume).
> I'll still post a patch to remedy it in the tests, but won't push it (unless
> you think that's worthwhile) and will file a bug instead.
Yep, lets at least wait & see what response we get to a bug report on this
issue.
I filed this BZ (and marked it as a regression):
https://bugzilla.redhat.com/show_bug.cgi?id=1674536
In the meantime, I also patched my local directory to work around the
difference (as well as adding the patch you sent today that you haven't
yet pushed) built a RHEL8 rpm, and updated my personal repo:
https://people.redhat.com/lstump/libvirt-tck-rhel8/
11:51 p.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On Mon, Feb 11, 2019 at 02:56:31PM +0000, Daniel P. Berrangé wrote:
On Mon, Feb 11, 2019 at 09:51:09AM -0500, Laine Stump wrote:
> On 2/11/19 6:11 AM, Daniel P. Berrangé wrote:
> > On Mon, Feb 11, 2019 at 06:07:40AM -0500, Laine Stump wrote:
> > > On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé
<berrange(a)redhat.com>
> > > wrote:
> > >
> > > > On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
> > > > > Since this test (050-apply-verify-host.t), we can't use a
regexp in
> > > > > the string to be compared. The fix method that leads to the
least
> > > > > changes is to use sed to remove potential leading 0's.
> > > > >
> > > > > Signed-off-by: Laine Stump <laine(a)laine.org>
> > > > > ---
> > > > >
> > > > > (These changes fix *almost* all failures in
> > > > > nwfilter/050-apply-verify-host.t on RHEL8. The rest look like
they
> > > > > might be legitimate problems with ebtables and IPv6)
> > > > Interesting, I swear I have previously got that test to succeed so
> > > > wonder what's changed since then !
> > > >
> > > I figured it out yesterday evening but haven't gotten a chance to post
it
> > > yet. I was being alarmist - its not a behavioral difference, but just a
> > > difference in how ipv6 addresses are formatted. The original ebtables
> > > reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::) while
> > > the iptables-ebtables package that RHRL8 is now using reports it with a
> > > prefix (/65). They probably hadn't switched packages yet the last time
you
> > > ran the test. I have a patch that modifies the expected output (and uses
> > > sed to modify the output from 'older' hosts, similar to what you
had done
> > > for RARP vs 0x8035) and will post it in a few hours, once I've had
coffee
> > > and tested on both types of host.
> > IMHO that should be reported as a bug against ebtables. The output format
> > of the new tools should be 100% identical tothe old tools. Changing from
> > a netmask to a prefix is a significant semantic difference that will break
> > too many uses.
>
>
> I thought about that, but wasn't feeling that ambitious since it was Sunday.
> If this is considered a bug, then changing the MAC address format from
> %x:%x:%x:%x:%x:%x to %0x:%0x:%0x:%0x:%0x:%0x should also be considered a
> bug.
Yes, I thought about that too. I think it would be worth raising that with
the maintainers to validate this was intentional. I get the feeling they'll
say that the old behaviour was a clear bug. If anything I'd probably ask
them to fix the old impl to not skip leading zeros too. IMHO mac addrs
should always be exactly the same length when printed.
> I'll still post a patch to remedy it in the tests, but won't push it
(unless
> you think that's worthwhile) and will file a bug instead.
Yep, lets at least wait & see what response we get to a bug report on this
issue.
Upstream has now taken a patch which changes the old ip6tables tool
to print the prefix, instead of netmask too, so we need to take this
patch of yours to the TCK
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
1:39 a.m.
New subject: [libvirt] [tck PATCH 5/4] nwfilter: account for more leading 0's in MAC addresses in ebtables output
On 2/15/19 10:51 AM, Daniel P. Berrangé wrote:
On Mon, Feb 11, 2019 at 02:56:31PM +0000, Daniel P. Berrangé wrote:
> On Mon, Feb 11, 2019 at 09:51:09AM -0500, Laine Stump wrote:
>> On 2/11/19 6:11 AM, Daniel P. Berrangé wrote:
>>> On Mon, Feb 11, 2019 at 06:07:40AM -0500, Laine Stump wrote:
>>>> On Mon, Feb 11, 2019, 5:50 AM Daniel P. Berrangé
<berrange(a)redhat.com>
>>>> wrote:
>>>>
>>>>> On Sat, Feb 09, 2019 at 02:03:05PM -0500, Laine Stump wrote:
>>>>>> Since this test (050-apply-verify-host.t), we can't use a
regexp in
>>>>>> the string to be compared. The fix method that leads to the
least
>>>>>> changes is to use sed to remove potential leading 0's.
>>>>>>
>>>>>> Signed-off-by: Laine Stump <laine(a)laine.org>
>>>>>> ---
>>>>>>
>>>>>> (These changes fix *almost* all failures in
>>>>>> nwfilter/050-apply-verify-host.t on RHEL8. The rest look like
they
>>>>>> might be legitimate problems with ebtables and IPv6)
>>>>> Interesting, I swear I have previously got that test to succeed so
>>>>> wonder what's changed since then !
>>>>>
>>>> I figured it out yesterday evening but haven't gotten a chance to
post it
>>>> yet. I was being alarmist - its not a behavioral difference, but just a
>>>> difference in how ipv6 addresses are formatted. The original ebtables
>>>> reports ipv6 addresses with a netmask (/ffff:ffff:ffff:ffff:8000::)
while
>>>> the iptables-ebtables package that RHRL8 is now using reports it with a
>>>> prefix (/65). They probably hadn't switched packages yet the last
time you
>>>> ran the test. I have a patch that modifies the expected output (and uses
>>>> sed to modify the output from 'older' hosts, similar to what you
had done
>>>> for RARP vs 0x8035) and will post it in a few hours, once I've had
coffee
>>>> and tested on both types of host.
>>> IMHO that should be reported as a bug against ebtables. The output format
>>> of the new tools should be 100% identical tothe old tools. Changing from
>>> a netmask to a prefix is a significant semantic difference that will break
>>> too many uses.
>>
>> I thought about that, but wasn't feeling that ambitious since it was Sunday.
>> If this is considered a bug, then changing the MAC address format from
>> %x:%x:%x:%x:%x:%x to %0x:%0x:%0x:%0x:%0x:%0x should also be considered a
>> bug.
> Yes, I thought about that too. I think it would be worth raising that with
> the maintainers to validate this was intentional. I get the feeling they'll
> say that the old behaviour was a clear bug. If anything I'd probably ask
> them to fix the old impl to not skip leading zeros too. IMHO mac addrs
> should always be exactly the same length when printed.
>
>> I'll still post a patch to remedy it in the tests, but won't push it
(unless
>> you think that's worthwhile) and will file a bug instead.
> Yep, lets at least wait & see what response we get to a bug report on this
> issue.
Upstream has now taken a patch which changes the old ip6tables tool
to print the prefix, instead of netmask too, so we need to take this
patch of yours to the TCK
Yeah, I was preparing to send the last patch, and the
nwfilter/050-apply-verify-host.t test began failing again so I'm looking
into it.
2072
days inactive
2079
days old
22 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
John Ferlan -
Laine Stump