From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: MARK target extension Date: Sun, 06 Jun 2004 16:25:12 +0200 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <40C32948.2090809@trash.net> References: <20040526205915.M56972@metal.art.pl> <40B5BA84.5040601@trash.net> <20040605205623.M81946@metal.art.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org Return-path: To: Grzegorz Nosek In-Reply-To: <20040605205623.M81946@metal.art.pl> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org Grzegorz Nosek wrote: > I had a look at the patch and it's indeed similar but supports only > single AND and OR operations and I think that it should allow more > flexibility. If you don't like the idea of adding another parameter, > maybe something like this would do: > --set-mark overrides all, without further questions > --and-mark and --or-mark are performed in sequence (thus more than one > allowed), so that (in my proposed syntax) > --set-mark 0x1234 --mask 0xffff > (leaving top 16 bits untouched) could be expressed as > --and-mark 0xffff0000 --or-mark 0x1234 > It shouldn't break any existing applications either (they're using > only one of the parameters now). > > It certainly is possible to get the same result using two consecutive > rules but it seems inefficient. I agree with you. CONNMARK seems to have the most flexible solution: newmark = (ct->mark & ~markinfo->mask) | markinfo->mark; Note that unlike with your patch, mark isn't ANDed with mask, so you can also do a simple OR by setting mask to zero. If you change your patch this way, and also make the userspace-part look like CONNMARK (mark/mask instead of --mask), I'll happily replace the MARK-operations patch. Regards Patrick