Re: [PATCH}: Make MARK target terminate (resend)
On Fri, Jul 05, 2002 at 12:01:21PM +0800, Fabrice MARIE wrote: Hello Harald, On Friday 05 July 2002 07:58, Harald Welte wrote: [...] yes. But then, how do we distinguish between terminating targets [where we can have only one per rule] and non-terminating targets AKA actions, where we can have multiple. You could just add a boolean field 'terminating' to the iptables_target. Then, make sure iptables abort and complains if it sees more than one terminating target being requested in a single rule. no, it's not about how to distinguish it internally. It was more like: How does the user know which targets terminate and which don't [just by looking at the name or it's usage] But now, if you don't want to use the match piggybacking trick that Jozsef Henrik mentionned, then we can't implement that right now. no. There is no reason in implementing it right now anyway. A change like this would not appeear in 2.4.x anyway... Do you think multiple targets is worth including in the design of the next netfilter framework ? it's not a big issue anyway. Instead of a fixed single target entry, there is a linked list. I'm already working on that code.. I bielieve we should do that, multiple actions for one condition is very natural, and I believe the usage of a custom chain for each of theses rules is a bit overkill.. yes, it helps in some cases, but not in all. Any thoughts ? Fabrice. -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
Re: [PATCH}: Make MARK target terminate (resend)
Hi Harald, On Fri, Jul 05, 2002 at 04:21:27PM +0200, Harald Welte wrote: You could just add a boolean field 'terminating' to the iptables_target. Then, make sure iptables abort and complains if it sees more than one terminating target being requested in a single rule. no, it's not about how to distinguish it internally. It was more like: How does the user know which targets terminate and which don't [just by looking at the name or it's usage] Random notice: the same question waits for the user who wants to understand the action of some previous user defined chain he just sees. Does that user defined chain terminate in any case? My point? iptables rulesets tend to become sufficiently complex in a short time so that vague inspection won't make a given ruleset easily understandable. IMHO that's a tribute to the flexibility we have with iptables. Engage brain before making modifications. have a nice weekend Patrick
Re: [PATCH}: Make MARK target terminate (resend)
On Tue, 2 Jul 2002, Harald Welte wrote: On Mon, Jul 01, 2002 at 09:50:18AM +0200, Balazs Scheidler wrote: On Sat, Jun 29, 2002 at 12:36:36PM +0200, Henrik Nordstrom wrote: On Saturday 29 June 2002 11.46, Patrick McHardy wrote: So the question to the Netfilter core team is if it would be OK to add a new option and module class to the userspace tools, and have the It is definitely useful. I'd love to have this additional flexibility. A couple of issues, though: 1) definitely 2.5.x thing - thus it should wait until pkt_tables becomes more apparent 2) I think this heavily confuses users, since a target can now be used as a 'match'. The current concept of netfilter/iptables is very clear and well-defined. Adding kludges like this sort-of breaks this concept... Also, no one answered the question yet on how to name an action module without breaking the current clear distiction in name between match and target modules. If the pseudo targets were converted to match modules, most of them could be unified with an already existing match module, which would result a more compact codebase (tcpmss/TCPMSS, ttl/TTL, tos/TOS, etc, etc.). I just repeat myself: the recent match is a nice example for this approach. - multiple targets It has been rejected several times with good reasons: too error-prone for the users and it would require heavy modifications both in the kernel and the userspace. the 'too heavy modification' issue is not really a problem anymore, since the undergoing 'pkt_tables' rewrite [shared infrastructure for iptables, ip6tables, arptables] and the linked-list rewrite. Then one should consider this approach as well. If we had the possibility to specify multiple targets then the current clean concepts could be kept as well. new action class: pro: no ordering problem pro: clean separation of functionalities con: naming issue match module: pro: no naming issue, current well known concepts can be kept pro: couple of modules can be unified con: ordering issue multiple targets: pro: no naming issue, current well known concepts can be kept pro: no change required in the existing modules con: ordering issue (-j ACCEPT -j TTL) Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
Re: [PATCH}: Make MARK target terminate (resend)
For the record: match module: pro: no naming issue, current well known concepts can be kept pro: couple of modules can be unified con: ordering issue I strongly prefer this solution, with the added requirement that order issues should be defined clearly, and have a clear relationship to the order given on the command line. If this is not the case now, this is the time to fix it, IMHO. best regards Patrick
Re: [PATCH}: Make MARK target terminate (resend)
On Wednesday 03 July 2002 14.41, Fabrice MARIE wrote: I proposed the last one some time ago. A solution to the ordering issue is to have two kind of targets: 1- terminal target (ie ACCEPT, DROP, REJECT, jump to chain, etc...) 2- non terminal target (ie TTL, MARK, IPV4OPTSSTRIP, etc...) The userland would basically use the order the admin provide, and would reply with an error if a non-terminal target is used after a terminal target. But I was answered that it was impossible/difficult with the current framework (which I agree). Not really. To address this in the current framework one only needs to piggyback on the match list. The kernel components needs to be modified to register themselves as matches as well as targets. The userspace components needs to be extended with a additional flag telling the userspace tool that the target is a non-terminal target and can be installed as a match in the kernel space table if multiple targets are used. The same datatypes should be possible to use for both the match info and the target info. I was also answered that it would break what people are used to, (having only one target) which I don't really agree with. Neither do I. Regards Henrik
Re: [PATCH}: Make MARK target terminate (resend)
Hi. Patrick Schaaf wrote: After not receiving a response for two weeks second try: Sorry. Here we go: The attached patch adds a new option --terminate to the MARK target which lets the user choose if MARK should return IPT_CONTINUE (normal behaviour) or NF_ACCEPT (to terminate further rule processing). [...] A CONNMARK patch will follow Will you also add this to LOG, ULOG, and any other IPT_CONTINUE target that may come up in the future? In my opinion, this is misguided, because it leads to much code duplication in target modules. Hmm probably not :) Although i can't see why someone would like (U)LOG to return NF_ACCEPT you're point is clear .. There is already a flexible, but somewhat ugly, way to do what you want: create a user defined chain that first MARKs then ACCEPTs (or does whatever else one may want to be done after MARK). Obviously, this is a bit ugly because you need one such chain per MARK value. Thats not really what i want to do .. especially since we need lots of marking rules, basically everything allowed needs to be marked with different values. The good way to do it, in my opinion, would be to permit more than one target per iptables rule. You could then write iptables -A somewhere -m something -j MARK --mark 1 -j ACCEPT Note that I do _not_ oppose adding your --terminate option to MARK, as a stopgap measure. If that is helpful now, it should be done, IMHO. However, I'd like to hear people's opinions on the multitarget approach. I like that idea very much, although (like Henrik already suggested) i favour the idea of something new between targets and matches for IPT_CONTINUE targets .. Bye, Patrick
Re: [PATCH}: Make MARK target terminate (resend)
On Mon, Jul 01, 2002 at 09:50:18AM +0200, Balazs Scheidler wrote: On Sat, Jun 29, 2002 at 12:36:36PM +0200, Henrik Nordstrom wrote: On Saturday 29 June 2002 11.46, Patrick McHardy wrote: So the question to the Netfilter core team is if it would be OK to add a new option and module class to the userspace tools, and have the existing IPT_CONTINUE targets dual-register as both a target and a match. I can try to whip something together if this is seen as something acceptable. Should be fully backwards/forward compatible with existing rulesets with only a minimal amount of code duplication. The only compability issue is that if you make use the new feature then you cannot go back to a older userspace or kernel.. I for one would second a feature like this. I see a good number of places where it could be used (the long standing missing -l option is one example) It is definitely useful. I'd love to have this additional flexibility. A couple of issues, though: 1) definitely 2.5.x thing - thus it should wait until pkt_tables becomes more apparent 2) I think this heavily confuses users, since a target can now be used as a 'match'. The current concept of netfilter/iptables is very clear and well-defined. Adding kludges like this sort-of breaks this concept... Bazsi -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
Re: [PATCH}: Make MARK target terminate (resend)
On Mon, Jul 01, 2002 at 11:47:09AM +0200, Jozsef Kadlecsik wrote: On Sat, 29 Jun 2002, Henrik Nordstrom wrote: [...] I proposed adding a new class of iptables things between matches and targets, being neither a match for filtering or a target that determines the ultimate fate of the packet. The names proposed for these in the discussion was modifiers or actions. I believe we have four possibilities - multiple targets It has been rejected several times with good reasons: too error-prone for the users and it would require heavy modifications both in the kernel and the userspace. the 'too heavy modification' issue is not really a problem anymore, since the undergoing 'pkt_tables' rewrite [shared infrastructure for iptables, ip6tables, arptables] and the linked-list rewrite. - a new class: actions With the new class, we would have to following skeleton of a rule: IP match data list of matches list of actions single target Using any action would make sense only when the target is ACCEPT and alike, so the actions function as 'always true' matches. One also has to note, that we have a nice, visible separation of matches and targets by name: matches are lowercased, while targets are uppercased. How could actions be fit into this scheme? How could one decide by glimpse that we are speaking about a match, action or target? [I'd name the new class as 'action' instead of 'modifier', because '-m' is reserverd but '-a' is not.] this sounds the most reasonable idea to me. In my opinion the match solution would be better, cleaner. I think introducing actions would be the way to go. but I'm not really convinced of any of the 'solutions'. Regards, Jozsef -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
Re: [PATCH}: Make MARK target terminate (resend)
Jozsef Kadlecsik wrote: - rewrite the IPT_CONTINUE targets as matches I am not very fond of this.. besides the order dependency it also has the question on how to easily determine what will happen with the packet.. No obvious distinction between something that matches packets and something that modifies packets or internal system state (conntrack, nfmark, ippools etc..). - do nothing: the problem can always be solved by introducing custom chains :-) Well.. Not really. Consider for example the LOG target where one wants to use the --log-prefix option to log different cases. Would require a custom chain per case which is quite cumbersome. But sure, it is in theory doable just as having all rules duplicated in a single chain is. So the question to the Netfilter core team is if it would be OK to add a new option and module class to the userspace tools, and have the existing IPT_CONTINUE targets dual-register as both a target and a match. I can try to whip something together if this is seen as In my opinion the match solution would be better, cleaner. So your current opinion is that the IPT_CONTINUE targets should be rewritten as matches? Regards Henrik
Re: [PATCH}: Make MARK target terminate (resend)
On Mon, 1 Jul 2002, Henrik Nordstrom wrote: - rewrite the IPT_CONTINUE targets as matches I am not very fond of this.. besides the order dependency it also has the question on how to easily determine what will happen with the packet.. No obvious distinction between something that matches packets and something that modifies packets or internal system state (conntrack, nfmark, ippools etc..). Nothing much can be do about order dependecy except the clear documentation of the feature. When the prestate/raw table will be ready (oh well, time...) then it'll be a good aid in spotting misconfigured rules. I see that the apparent distinction between true matches and matches with side effect would be lost compared to the case of separated matches, actions. Hoewer, would it help to the end user if there were a separated interface to the matches with side-effect (actions)? What would be the rule for an action name? I fear it would create a confusion about which module is a match, which one is an action if an action name would be lowercased. Something new must be introduced. The question is which one more coherent *and* more user-friendly. In my opinion the match solution would be better, cleaner. So your current opinion is that the IPT_CONTINUE targets should be rewritten as matches? This is my current personal opinion. The naming issue of actions really disturbs me. Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
Re: [PATCH}: Make MARK target terminate (resend)
After not receiving a response for two weeks second try: Sorry. Here we go: The attached patch adds a new option --terminate to the MARK target which lets the user choose if MARK should return IPT_CONTINUE (normal behaviour) or NF_ACCEPT (to terminate further rule processing). [...] A CONNMARK patch will follow Will you also add this to LOG, ULOG, and any other IPT_CONTINUE target that may come up in the future? In my opinion, this is misguided, because it leads to much code duplication in target modules. There is already a flexible, but somewhat ugly, way to do what you want: create a user defined chain that first MARKs then ACCEPTs (or does whatever else one may want to be done after MARK). Obviously, this is a bit ugly because you need one such chain per MARK value. The good way to do it, in my opinion, would be to permit more than one target per iptables rule. You could then write iptables -A somewhere -m something -j MARK --mark 1 -j ACCEPT Note that I do _not_ oppose adding your --terminate option to MARK, as a stopgap measure. If that is helpful now, it should be done, IMHO. However, I'd like to hear people's opinions on the multitarget approach. best regards Patrick
Re: [PATCH}: Make MARK target terminate (resend)
On Saturday 29 June 2002 11.46, Patrick McHardy wrote: A CONNMARK patch will follow but currently CONNMARK doesn't apply clean against 2.4.18/2.4.19-pre10 .. Note: There is two versions of the CONNMARK patch. The one in extra applies if you are using the new_nat patch, the one on old_nat if not. Your last posting did stir up some discussion on how to deal with this. Adding a terminate option to each and every of these psuedo-targets is clearly not the way to go, and only cover a very small subset of what is needed. I proposed adding a new class of iptables things between matches and targets, being neither a match for filtering or a target that determines the ultimate fate of the packet. The names proposed for these in the discussion was modifiers or actions. The implementation of these can be done without needing to change the kernel iptables API by simply piggying back on the match list in the table structure. The modifiers/actions need to register themselves as a match, and for compability with old rulesets and/or userspace tools as a target as well.. The userspace tools need to have a new option for calling a modifier/action. These should clearly be separated from matches. So the question to the Netfilter core team is if it would be OK to add a new option and module class to the userspace tools, and have the existing IPT_CONTINUE targets dual-register as both a target and a match. I can try to whip something together if this is seen as something acceptable. Should be fully backwards/forward compatible with existing rulesets with only a minimal amount of code duplication. The only compability issue is that if you make use the new feature then you cannot go back to a older userspace or kernel.. Regards Henrik
