----- Original Message ----- From: "Lennert Buytenhek" <[EMAIL PROTECTED]> To: "Bart De Schuymer" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, January 06, 2002 7:24 PM Subject: Re: [Bridge] [PATCH] bridge-nf-0.0.4.bis patch available
(dunno if this message got delivered, so a resend..) > > Ok, but my main point was that the nf bridge priority of passthrough should > > be INT_MAX, no matter what name you give it. > > Please allow me to disagree. Ofcourse. But could you elaborate on why you give them priority number 0 instead of something near INT_MAX? I agree 0 is a cool looking number. Any other reason? > > > Any function that attaches to a netfilter hook after the passthrough > > function might as well attach before the passthrough function: > > - if the function does stuff for ip packets it gets useless if it attaches > > after the passthrough function because passthrough steals those packets. > > *That* is the bug. We should definitely call NF_HOOK_THRESH after the > passthrough functions. Isn't NF_HOOK_THRESH called _inside_ the br_nf_local_out() function of 'passthrough'? I don't think that's a bug. I'll give a concrete example of what I meant in my previous post. Suppose the ebtables functions had priorities >0 (their actual priorities are <0). Then any rule in ebtables that the user makes and that should also affect ip packets, won't do quite the job. Because the passthrough function _steals_ the ip packets before the ebtables functions get a chance to look at them. So, then you can have unexpected behaviour when iptables allows the packet but ebtables doesn't. Now, you can ofcourse say that the author of ebtables should then know better and make the priorities <0. This is ok if there is a reason for other functions to have priorities >0. But there isn't any reason. Any function that works correctly with a priority >0 would work correctly with a priority <0 too (with the passthrough functions having priority 0), with exactly the same behaviour. So, there is no reason for the passthrough functions to have a priority of 0 or something close to 0, while there is a good reason for them to have a priority close to INT_MAX. > > > > - Give sabotage functions netfilter priority NF_IP_PRI_FIRST (i.e. > > INT_MIN), > > > > except for NF_IP_LOCAL_OUT ofcourse > > > > > > For PRE_ROUTING I agree, for FORWARD not really. There just happens to be > > > nothing before PRI_BRIDGE_SABOTAGE, but I'm sure there could be hooks > > > interested in the 'original' (i.e. possibly un'flooded') packet. > > > > Ok, but naming that priority also NF_IP_PRI_BRIDGE_SABOTAGE is misleading. > > In essence I believe the priorities for SABOTAGE on NF_IP_LOCAL_OUT and > > NF_IP_FORWARD are unrelated. It just happens that that value (-50) works for > > both hooks. > > Well, IPv4 does the same thing with hook priorities. I think it does make > sense in a way. I agree it's more goodlooking. Anything makes sense in some way though. > > Couldn't we put something like (INT_MIN + 10)? > > Suppose someone has an ip netfilter function and decides to put it at > > priority value -60 (not knowing about passthrough). > > (This is why we need 'proper' priority registration :) Yes, exactly why it's proper for us to not mess with normal iptables behaviour. If someone wants to write a function that has a higher priority than the SABOTAGE function, then he will know about the INT_MIN +10 or whatever priority value of SABOTAGE. However, do you really want to impose on anyone who wants to write an iptables function that they know the deal about the -50 priority value for that special, funny SABOTAGE function? This patch isn't in the standard kernel. So suppose some function with priority -60 gets into the standard kernel. Then we need to go change the priority for SABOTAGE... The sabotage priority question is a matter of taste I guess, but I do think it's bad to have priority 0 for the passthrough functions. cheers, Bart _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
