[libvirt] [PATCH] nwfilter: allow for different format of IPv6 netmask/prefix in ebtables output

Laine Stump laine at laine.org
Fri Feb 22 14:58:45 UTC 2019


On 2/21/19 1:02 PM, Daniel P. Berrangé wrote:
> On Fri, Feb 15, 2019 at 01:21:50PM -0500, Laine Stump wrote:
>> The iptables-ebtables package is meant as a drop-in replacement for
>> the native ebtables package, but it formats some items in the -L
>> output differently, leading to failure of scripts that depend on the
>> output of ebtables -L. In particular:
>>
>> with old ebtables IPv6 prefixes are output as a netmask (e.g.: "/ffff:fc00")
>>
>> with iptables-ebtables IPv6 prefixes are always output as a numeric
>>     prefix (e.g. "/22"), and suppressed completely if the prefix is
>>     /128.
>>
>> This difference is also described in
>> https://bugzilla.redhat.com/show_bug.cgi?id=1674536
>>
>> "old" ebtables upstream has just accepted a patch to change its output
>> to match that of iptables-ebtables:
>>
>> https://marc.info/?l=netfilter-devel&m=155000828923204&w=2
>>
>> so it makes sense for libvirt-tck to accept the new format (as well as
>> the old). As with the patch for fixing up MAC addresses with leading
>> 0s, this patch also uses sed to apply a substitution to the scraped
>> output of ebtables -L. However, rather than keeping the comparison
>> (expected) output in the old (netmask) form, it is changed to the new
>> (prefix) form, and the sed commands change netmasks to prefixes. (This
>> works out better because in some cases we need to replace [all ff's]
>> with "", and it's not possible to do that in the opposite direction
>> :-)
> Ok, so you're not doing a real netmask -> prefix convertor. You've
> just hardcoded the conversions we need given our expected data.
> This looks fine to me as a prudent approach.


Yeah, I didn't want to touch that shell script any more than absolutely 
necessary :-) (I suppose I could have added a small utility to 
find/replace generic netmasks, and call that as a part of the line of 
commands in the test cases, but I'd be just as likely to introduce a new 
bug)





More information about the libvir-list mailing list