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)