Re: 2.6.12: connection tracking broken?

From: Patrick McHardy
Date: Wed Jun 22 2005 - 22:29:15 EST

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.


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

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at