Messages in this thread | | | Date | Thu, 23 Jun 2005 05:26:30 +0200 (CEST) | From | Patrick McHardy <> | Subject | Re: 2.6.12: connection tracking broken? |
| |
On Thu, 23 Jun 2005, Herbert Xu wrote: > Longer term though we should obsolete the ipt_physdev module. The > rationale there is that this creates a precedence that we can't > possibly maintain in a consistent way. For example, we don't have > a target that matches by hardware MAC address. If you wanted to > do that, you'd hook into the arptables interface rather than deferring > iptables after the creation of the hardware header.
Agreed.
> This can be done in two stages to minimise pain for people already > using it: > > 1) We rewrite ipt_physdev to do the lookups necessary to get the output > physical devices through the bridge layer. Of course this may not be > the real output device due to changes in the environment. So this should > be accompanied with a warning that users should switch to ebt.
IMO without defering the hooks the physdev match becomes pretty useless for locally generated packets. The bridge layer clones packets that are delivered to multiple ports and calls the NF_IP_* hooks for each clone, so each clone can be treated seperately. In the IP layer there is only a single packet, so clones for different ports couldn't be treated seperately anymore and the semantic of the physdev match would need to be changed to match on any bridge port in this case, which would probably break existing rulesets.
> 2) We remove the iptables deferring since ipt_physdev will no longer need > it. > > 3) After a set period (say a year or so) we remove ipt_physdev altogether.
How about we schedule it for removal in a year, keep the workaround until then and then remove the hook defering?
Regards Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |