From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [CTNETLINK] Rework conntrack fields dumping logic on events Date: Thu, 23 Nov 2006 14:56:41 +0100 Message-ID: <4565A899.3050609@trash.net> References: <4553D3D5.40408@netfilter.org> <4557B157.6010205@netfilter.org> <45659FBA.2020505@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Harald Welte , Netfilter Development Mailinglist , Pablo Neira Ayuso Return-path: To: Jozsef Kadlecsik In-Reply-To: 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 Jozsef Kadlecsik wrote: > Hi Patrick, > > On Thu, 23 Nov 2006, Patrick McHardy wrote: > > >>>The attached patch (on top of Patrick's nf_nat git tree and my patches >>>sent to this list) implements what I suggested: *do* register the helpers >>>which are actually assigned by an expectfn. Thus ctnetlink can find them >>>by name and then fill conntrack with the helper. In order to make sure a >>>bogus packet can't trigger such helpers, __nf_ct_helper_find had to be >>>modified. What do you think? >> >>This is something needed for userspace-helpers (Harald did some work >>in this direction), but I can't really think of what it could be used >>for currently. > > > It is required at conntrack replication if/when the H.323 helper is in > use. The H.245 helper is currently not registered so there is no > way to replicate the helper: the name is passed but the other side is > unable to find the helper on the list of the registered helpers. Good point :) But instead of overloading tuple semantics a flag would be cleaner IMO and would allow us to skip them quickly