----- Original Message ----- From: "Lennert Buytenhek" <[EMAIL PROTECTED]> Sent: Saturday, April 06, 2002 4:14 PM Subject: Re: [Bridge] DNAT'ing
> > Aha, now I get it :-) > > Never did quite understand br_nf_pre_routing_finish. > > Hmm.. should I add a big fat comment over it? A note saying that doing skb->dst->output(skb) doesn't give security risks, because it gets fixed in br_nf_local_out would help alot for a codereader. > OK.. how does this look? Looks good. > Any other submissions for 0.0.7? Do you still want me to add > those PF_BRIDGE priorities you sent me a while ago? I would appreciate them, but I can perfectly well live without them... However, there might be a problem with the NF_BR_FORWARD priority (-200), see below. Some notes: 1. The way br_netfilter now works can give unnatural ebtables chain traversals. The following I just tested: Take a bridge with 2 interfaces. On each interface is a computer, both have a different network address. If they ping to each other the messages go via their default gateway, being the bridge. Then the ip packets will traverse the ebtables chains in this manner: PREROUTING-->INPUT ..... FORWARD-->POSTROUTING. This is not the correct way, the correct way (according to me) is PREROUTING->INPUT ...... OUTPUT->POSTROUTING. The reason is because in br_nf_local_out there is only a check on skb->physindev. This is good for getting the iptables chain traversal right, but is not enough for ebtables... The same thing will happen even if the bridging box has 2 logical bridges and traffic is routed between these two. Also when traffic is DNATed (without explicitly routing) to the other logical bridge, the ebtables FORWARD chain will be passed instead of the OUTPUT chain. 2. The priority for the ebtables FORWARD chain is currently -200. This causes the chain traversal for the above mentioned situation to actually go like this: PREROUTING-->INPUT ..... POSTROUTING. instead of PREROUTING-->INPUT ..... FORWARD-->POSTROUTING. Certainly not acceptable, now nor the ebtables FORWARD nor the INPUT chains are traversed... This is because NF_HOOK_THRESH in br_nf_local_out_finish_forward only starts from 1. I realize that you can't just allow all the priorities in this function because then the iptables FORWARD chain is traversed twice. But maybe there is a way to tell the br_nf_forward not to play with those packets. Could one put skb->physindev to NULL in br_nf_local_out_finish_forward and check on this in br_nf_forward without breaking anything? If this or something similar is possible, we can do a NF_HOOK instead of a NF_HOOK_THRESH in br_nf_local_out_finish_forward. I have a reason for having the priority -200 for the ebtables FORWARD chain. I think, in pure bridging, it's more logical to first traverse the ebtables FORWARD chain and after that the iptables FORWARD chain. 3. Are you aware that functions registering on BR_NF_LOCAL_OUT with priority < 0 will also be executed for 'bridged' packets? This because br_nf_local_out has priority 0. Maybe it's better to make this INT_MIN. Hope I am making sense here... cheers, Bart _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
