From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amin Azez Subject: Re: dangerous? Setting mark in nat table Date: Wed, 14 Mar 2007 12:43:03 +0000 Message-ID: <45F7EDD7.4070906@ufomechanic.net> References: <45F6CD7C.40708@ufomechanic.net> <1173868532.26913.39.camel@henriknordstrom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org, Jan Engelhardt To: Henrik Nordstrom Return-path: In-Reply-To: <1173868532.26913.39.camel@henriknordstrom.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org * Henrik Nordstrom wrote, On 14/03/07 10:35: > tis 2007-03-13 klockan 17:18 +0100 skrev Jan Engelhardt: > > >> http://lkml.org/lkml/2006/8/22/26 >> >> CONNMARK does in filter, MARK does not - I do not know what is >> supposed to be going on. >> > > It's due to the relation of the per-packet nfmark being as a channel to > return routing information from netfilter to the kernel. Thats exactly how I'm trying to use it, which is why I need to set it in the nat table. (I know that nat only applies to the first packet in a flow, I also use CONNMARK later to save the mark combined with other data.) > The > per-connection conntrack mark used by CONNMARK does not have this > property and does not need to be restricted in where it's modified. > > The restore operation of CONNMARK have the same restrictions as MARK as > it too modifies the packet nfmark, and can therefore only be used from > mangle just as MARK. > Now this at least makes a little sense. Sam