[libvirt] [PATCH] nwfilter: enable bridge netfilter calls via proc filesystem

[Stefan Berger]

  On 09/22/2010 02:25 PM, Eric Blake wrote:
> On 09/22/2010 12:19 PM, Stefan Berger wrote:
>> On a recent installation of FC13, the filtering of IP/IPv6 using
>> iptables/ip6tables traffic did not work since the proc filesystem
>> entries /proc/sys/net/bridge/bridge-nf-call-iptables and
>> /proc/sys/net/bridge/bridge-nf-call-ip6tables contained a zero each and
>> no traffic went into the FORWARD chain. The patch below makes sure that
>> if iptables or ip6tables are being used by the nwfilter driver that a
>> '1' is written into the relevant proc filesystem entry so that the
>> traffic goes into the FORWARD chain.
>
> Do we have to worry about a minimum kernel version where these 
> /proc/sys files are guaranteed to exist?
How would I find out? At least on the machines I have looked, these proc 
filesystem entries do exists -- just that they already contain the 
expected '1'. I don't know what used to write the '1' into these files, 
but it doesn't do it anymore on the other 2 systems I installed, 
possible due to packages that I have installed on other systems but not 
on the new ones.

My assumption is that on systems where these files exist, writing a '1' 
into them won't hurt. If they don't exist then the expected behavior is 
activated by default.

>
>> virBufferVSprintf(buf,"%s -N " VIRT_IN_CHAIN CMD_SEPARATOR
>> "%s -N " VIRT_OUT_CHAIN CMD_SEPARATOR
>> "%s -N " VIRT_IN_POST_CHAIN CMD_SEPARATOR
>> - "%s -N " HOST_IN_CHAIN CMD_SEPARATOR,
>> + "%s -N " HOST_IN_CHAIN CMD_SEPARATOR
>> + "echo 1 > %s" CMD_SEPARATOR,
>
> Not introduced by this patch, but shouldn't you be checking individual 
> commands for appropriate exit status?  And with this particular patch, 
> what happens when a successful exit status of 'echo 1 >file' masks an 
> earlier failure of the iptables_cmd?
>
The particular sequence of above 4 commands (above the echo) is run 
quite frequently and they may fail if for example the tables already 
exist. If they did not succeed for some other reason, then subsequent 
commands trying to establish a 'jump' into one of these tables will then 
fail (see code following below the patch in the same function) and 
report back. So error codes in this case can be masked.

   Stefan