From: "Lennert Buytenhek" <[EMAIL PROTECTED]> Sent: Thursday, April 11, 2002 5:06 PM > > > 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..
Okay. > > 1. > > I think that this is the problem that I just acknowledged. I see > the light now. Right. > > 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? As said in my last reply we have the skb->dst->output case that gives problems because ebtables FORWARD is on priority -200. > > 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. The problem is that 0.0.6 wants to give bridged packets passing BR_NF_LOCAL_OUT to functions registered on BR_NF_FORWARD. This is a very good idea, but the issue is that only the functions registered on BR_NF_FORWARD with priority > 0 get to see the packet. Why should they know about this? Why should they have to register with positive priority so they don't get discriminated? It's a democracy, let all BR_NF_FORWARD functions see the packets, no matter if their preference is negative or positive. > > 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? Well, it does matter a little. You can e.g. log stuff in the ebtables FORWARD chain and then be surprised that none (some) of the ip packets (don't) get logged, e.g. because iptables drops them. It's more logical (atleast for me) from an outside view that the ebtables FORWARD chain is traversed before the iptables FORWARD chain. As a bridge is a layer 2 device one would expect layer 2 filters to see the packets first. I could live with the iptables FORWARD chain seeing the packets before the ebtables FORWARD chain if things get too nasty the other way around. But then I suggest making the br-nf hook's BR_NF_FORWARD priority INT_MIN, because the bridge-nf is then so invasive that skb->dst->output case packets, which are really bridged packets, won't be seen by functions hooked onto NF_BR_FORWARD with priority below that of the br-nf hook's BR_NF_FORWARD priority. So, to prevent any wrong assumptions one should explicitly make sure every function can only register onto BR_NF_FORWARD with a higher priority than br-nf's. > > 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). No confusion here from my part. What I am saying is that functions that register onto BR_NF_LOCAL_OUT with priority below 0 will always see the packets passing through BR_NF_LOCAL_OUT. So: it won't matter if these packets are actually bridged or actually routed. This is not good. Without br-nf this would not happen. It is br-nf's invasive nature that causes this and it should clean up after itself. And it does this only partly because the function that is supposed to do this is registered with priority 0 on BR_NF_LOCAL_IN. It should not be demanded from any regular BR_NF_LOCAL_OUT function "Jane" to know about the behaviour of br-nf. So if Jane wishes to register onto BR_NF_LOCAL_OUT with a negative priority she should never see bridged packets passing through. The easy way to solve this is making the br-nf BR_NF_LOCAL_OUT priority INT_MIN. > 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. I think all that "nasty sh*t" is very good. It's perfectly possible (atleast in theory) to get the ebtables chain traversal right with some modifications to your current logic and as far as I can tell your logic is necessary to get iptables working correctly. I believe users knowing enough about networks to use ebtables correctly will find it logical that routed packets between 2 bridge port groups pass through ebtables in the PREROUTING->INPUT->OUTPUT->POSTROUTING manner. And if they don't they should learn it :) > Does this make sense at all? Yeah, though our mails are getting lengthy. We should write a book ;) cheers, Bart _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
