Patrick McHardy wrote:
> Eric Dumazet wrote:
>
>> Le mardi 30 mars 2010 à 16:16 +0200, Bart De Schuymer a écrit :
>>
>>> @@ -163,7 +166,11 @@ static inline bool __nf_ct_tuple_dst_equ
>>> {
>>> return (nf_inet_addr_cmp(&t1->dst.u3, &t2->dst.u3) &&
>>> t1->dst.u.all == t2->dst.u.all &&
>>> - t1->dst.protonum == t2->dst.protonum);
>>> + t1->dst.protonum == t2->dst.protonum
>>> +#ifdef CONFIG_BRIDGE_NETFILTER
>>> + && likely(t1->dst.vlan_id == t2->dst.vlan_id)
>>> +#endif
>>> + );
>>> }
>>>
>>> static inline bool nf_ct_tuple_equal(const struct nf_conntrack_tuple *t1,
>>>
>>>
>> This really sounds very strange, layering violation or something.
>>
>> You mix conntracking, bridge and vlan here.
>>
>
> I agree, this is really wrong.
>
Using the conntrack zone workaround to achieve what my patch does is
basically doing the same thing, IMHO.
But it's indeed much cleaner to use the generic CT target scheme, which
also solves the "multiple bridges" scenario mentioned by Pascal. I
wasn't yet aware of this target.
I've tested the following setup with 2.6.34-rc3 and it successfully
separates the networks (without my vlan patch).
# set up the connection tracking zones
iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone 1
iptables -t raw -A PREROUTING -m mark --mark 2 -j CT --zone 2
# mark packets according to the vlan id
ebtables -t nat -A PREROUTING -p 802_1Q --vlan-id 1 -j mark --mark-set 1
ebtables -t nat -A PREROUTING -p 802_1Q --vlan-id 5 -j mark --mark-set 2
So this is good news. The security risk is solvable starting from
v2.6.34. I'll need to mention this clearly in the documentation.
What about the other patches? I'm aware they don't all cleanly patch
versus the most recent kernel, but do you have any objections apart from
that?
cheers,
Bart
--
Bart De Schuymer
www.artinalgorithms.be
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
