On Sat, Apr 06, 2002 at 07:38:22PM +0200, Bart De Schuymer wrote:
> > > 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, I think my doc patch ought to be clear enough. Sorry for not having documented this earlier. > > 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... So is that a yes or a no? :) Just send me a patch and I'll add them.. > 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. I think that this is the problem that I just acknowledged. I see the light now. > 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. Isn't the problem that br_nf_local_out_finish_forward exists in the first place? Routed packets have nothing to do with NF_BR_FORWARD. Doesn't fixing problem 1 imply fixing problem 2? > 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'm not sure what you mean here. I really don't think we should mess with NF_BR_FORWARD in br_nf_local_out_finish. > 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. I guess it doesn't really matter either way, does it? > 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. Ah, ok, I think I see where the confusion between us comes from now. Bridged packets should go through BR_NF_FORWARD and not BR_NF_LOCAL_OUT. The only packets that go through BR_NF_LOCAL_OUT that were-originally-meant-to-be-bridged are cross-bridge DNAT'ed packets. But these packets really _are_ routed, not bridged (think about it for a while, and read the comment about it in my earlier docs patch). What I'm seeing with ebtables here and there is that it's bothered by the same 'impedance mismatch' that bridge-nf once was. I.e., the 'correct' way of doing bridge firewalling is to have routed packets go through the bridge input and output chains. I purposefully decided not to take this route, because it's not logical to the end user, and see what grief my decision has caused: the nasty intercept-and-reinject-later logic, the very nasty DNAT logic, etc. Does this make sense at all? cheers, Lennert _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
