<tt>Eric Blake <eblake@redhat.com> wrote on 03/10/2014 06:05:18 PM: > From: Eric Blake <eblake@redhat.com></tt> <tt> > 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?</tt> <tt>I must say, I did not test whether the iptables rule in this particular case</tt> <tt>did not work. I assumed that if it applies, it will work. And besides that</tt> <tt>it is supposed to work in the FORWARD chain (following dmesg) and we now have</tt> <tt>a case where the rule is accepted in a chain that is connected to the FORWARD</tt> <tt>chain and is rejected in a chain that is also connected to the FORWARD chain.</tt> <tt>Both chains are not connected to the FORDWARD chain directly but there is one</tt> <tt>other chain in between. It may be that iptables walks these chains to see whether</tt> <tt>they are connected to the FORWARD chain but for some reason doesn't do it</tt> <tt>correctly for the 2nd case.</tt> <tt>It still applies in 3.10.</tt> <tt> > > > > +++ 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</tt> <tt>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.</tt> <tt> > 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 ) ></tt> <tt>Will fix.</tt> <tt>Stefan</tt>