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)
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
