[libvirt] [PATCH] nwfilter: Deactivate iptables MAC address check where needed

Stefan Berger stefanb at us.ibm.com
Mon Mar 10 22:58:12 UTC 2014


Eric Blake <eblake at redhat.com> wrote on 03/10/2014 06:05:18 PM:

> From: Eric Blake <eblake at redhat.com>

> On 03/10/2014 02:49 PM, Stefan Berger wrote:
> > From: Stefan Berger <stefanb at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140310/65473290/attachment-0001.htm>


More information about the libvir-list mailing list