Eric Blake <eblake@redhat.com> wrote on 03/10/2014
06:05:18 PM:
> From: Eric Blake <eblake@redhat.com>
> On 03/10/2014 02:49 PM, Stefan Berger wrote:
> > From: Stefan Berger <stefanb@linux.vnet.ibm.com>
> >
> > Recent Linux iptables (3.11.7) refuses to create iptables MAC
address
> > check rules using -m mac --mac-source <addr> where previous
versions
> > still allowed it. So we now need to deactivate the filtering
rules for
> > when the incoming traffic is filtered before it is sent into
the VM.
> > Those are typically the chains that start with FO-* or start
with FP-*
> > when they are being built.
> >
> > Adapt the documentation to reflect the fact that srcmacaddr,
when
> > used in iptables rules, should be regarded as deprecated due
to the
> > above mentioned problems.
>
> Is this an unintentional kernel regression, or something that we were
> doing wrong all along and the kernel is now finally calling our bluff?
I must say, I did not test whether the iptables rule
in this particular case
did not work. I assumed that if it applies, it will
work. And besides that
it is supposed to work in the FORWARD chain (following
dmesg) and we now have
a case where the rule is accepted in a chain that
is connected to the FORWARD
chain and is rejected in a chain that is also connected
to the FORWARD chain.
Both chains are not connected to the FORDWARD chain
directly but there is one
other chain in between. It may be that iptables walks
these chains to see whether
they are connected to the FORWARD chain but for some
reason doesn't do it
correctly for the 2nd case.
It still applies in 3.10.
>
>
> > +++ b/docs/formatnwfilter.html.in
> > @@ -1209,7 +1209,7 @@
> > <tr>
> > <td>srcmacaddr</td>
> > <td>MAC_ADDR</td>
> > - <td>MAC address of sender</td>
> > + <td>MAC address of sender;
this option is deprecated</td>
>
> Marking something as deprecated is one thing...
>
> > </tr>
> > <tr>
> > <td>srcipaddr</td>
> > @@ -1320,22 +1320,7 @@
> > <tr>
> > <td>srcmacaddr</td>
> > <td>MAC_ADDR</td>
> > - <td>MAC address of sender</td>
> > - </tr>
> > - <tr>
> > - <td>srcmacmask</td>
> > - <td>MAC_MASK</td>
> > - <td>Mask applied to MAC address
of sender</td>
> > - </tr>
>
> ...but completely removing documentation feels wrong. Was this
bogus
> documentation, or do we still support usage of this XML on older kernels
> that don't prohibit it? Maybe separate this into multiple patches
- doc
This was bogs documentation. Must have been a c&p
error. srcmacmask only exists for rules mapping into ebtables rules, but
that's not the case here.
> fixes (deleting stuff that never worked) vs. deprecation (marking
stuff
> that no longer works on newer kernels).
>
> > @@ -984,6 +984,14 @@ iptablesHandleSrcMacAddr(virBufferPtr buf,
> > return 0;
> > }
> >
> > + /* recent Linux iptables does not
allow this filteirng rule to be
>
> s/filteirng/filtering/
>
> > + * applied to all FO-* chains
> > + */
> > + if (chain[1] == CHAINPREFIX_HOST_OUT_TEMP
) {
>
> No space before )
>
Will fix.
Stefan