From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Subject: Re: tc ipt action Date: Wed, 19 Dec 2012 06:43:25 -0500 Message-ID: <50D1A85D.1020302@mojatatu.com> References: <50C4821D.5090206@gmail.com> <50C9B4BB.9060609@mojatatu.com> <50CCE961.5050204@mojatatu.com> <20121216002755.GA11773@1984> <50CDA5BE.2080800@mojatatu.com> <50CE0921.7060306@mojatatu.com> <50CE307E.40304@mojatatu.com> <50CF16FE.5040300@mojatatu.com> <50D06E66.8000600@mojatatu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pablo Neira Ayuso , Yury Stankevich , shemonc@gmail.com, "netdev@vger.kernel.org" , netfilter-devel@vger.kernel.org To: Jan Engelhardt Return-path: In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 12-12-18 08:58 AM, Jan Engelhardt wrote: > > Chains can store multiple targets, so no loss. Nice. > 1. table > > First, I think some targets need to relax their restrictions, such as > with xt_DSCP. Saw your other patch to get rid of mangle hardcoding. > Then, only a handful of extensions remain: CT, , > TPROXY and REJECT. Would anyone want to call these from act_ipt? > I doubt it. :) > Tempted to say tproxy. > 2. hooks > > Extensions with hook limit: , TPROXY, REJECT, CLASSIFY. > Again, I don't quite see the value of attempting to NAT from act_ipt. > CLASSIFY {c|sh?}ould be relaxed, unless I am missing something. > I could live with that. It would be an improvement over whats there today. I would prefer however for this to be an improvement over act_xt.c i posted as opposed to have even more interfaces for xt. We've suffered enough already ;-> i.e add your patches on top. cheers, jamal