21.03.2013 0:41, Laine Stump wrote:
[...]
- !!(info->invert_flags& XT_CONNTRACK_DIRECTION))
+ !(info->invert_flags& XT_CONNTRACK_DIRECTION))
return false;
if (info->match_flags& XT_CONNTRACK_ORIGSRC)
So apparently, netfilter's behaviour was indeed reversed at some
point, therefore libvirt stopped working properly.
To save me the trouble, can you point me at a copy of the patch so I can
read the commit message?
Maybe this
http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/38602
and this
http://git.opencores.org/?a=commit&p=linux&h=96120d86fe302c006259baee9061eea9e1b9e486
will be of some use.
That seems a very bad thing to do :-/
I'd guess libvirt needs to be adapted then? Is it a known issue or
should I fill in bugreport at Novell/Red Hat?
I suppose it needs to be adapted, but how are we supposed to know which
way to go? Some magic number of kernel version?
Yeah, makes me wonder.
Anyway, I've filed a bugreport at Novell (with a trivial patch proposed,
although not taking into account possible "older" kernels hanging around
with "historical" behaviour)
https://bugzilla.novell.com/show_bug.cgi?id=810611
Nikolai
Bah. (This is the 2nd issue this week caused by a change in kernel ABI,
so I'm not in a good mood...)
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
