Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2116650imm; Thu, 9 Aug 2018 07:35:28 -0700 (PDT) X-Google-Smtp-Source: AA+uWPw5UM3Fmr3GNhc8WiIGYQ3SJBQCNfsh+QUXT6GPkGOCEbpqgh2wPS2br9h6Kzf82I3/I5aF X-Received: by 2002:a62:398c:: with SMTP id u12-v6mr2683692pfj.9.1533825328281; Thu, 09 Aug 2018 07:35:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533825328; cv=none; d=google.com; s=arc-20160816; b=uTILDctaUui5S8YM018/hVGmu7ocNWhJ6qyJEgrXR9SM2Ttbg7MNlD9/nt+PgBznvH OoneLa6lW/RovwHqov7alk53xjMJFDVyK4KkCbnishvVkUdDGq2VFEosJJVSpXOx4Uwg lvsE2gP+gBhpvCd4Ca9Kieh4+m09POWOjV7D+usZA8scSJ0882kztetEN4jlg/9C/lIJ TWcAQuuJHSDLs29BdqFaBIserLc92NKYbUEyK5Ifu45+eSELO8RsYEUHxiDbu7hD43fs JlSTHvL0yGGxRxipxbL6OBs19NSe6sLj2EDzvwXFgGQ97DOuYU5bsqzXh/XB92aW2WQt 3HWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:user-agent:references:message-id:lines :date:subject:from:to:arc-authentication-results; bh=r56vQvvq2q5OB/n1RyamqgGgKtzjV/vHxmRCwgOYz1w=; b=CK4pZZgxvEprwM4cgGXNHH+hSq0S9MVBoNFBaR6w+tSE1NUXIq5ZUeArvsqB3ZTynm xxnX9lqs0NcILJpf7NHTiSrECVzK5wlyf3SmbIjsunqojmZCZNQ5F6s9nTXBPR26qy6t qKm6VLH49hOdS/TA8ViTc3xvk3KWGOP2qDg9fC9IGTKN7gmBVJcN3LEdCUxrML0rqCM1 iD2ASzPn4SG924j/ApmjLiXVKBGkL3X9ChVzFkPh4sUlH16n/qP/ZNHriWSVgaujWnrt Nr1uogBh1pzyyk0m/EuACf1aZDYdri7kbC7gdCqyl2UgwiqsKSnEJigu1wDIDPEmD5Oh DRrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 63-v6si7084676plb.288.2018.08.09.07.35.14; Thu, 09 Aug 2018 07:35:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732313AbeHIQ6y (ORCPT + 99 others); Thu, 9 Aug 2018 12:58:54 -0400 Received: from [195.159.176.226] ([195.159.176.226]:36235 "EHLO blaine.gmane.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1730453AbeHIQ6y (ORCPT ); Thu, 9 Aug 2018 12:58:54 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fnlyM-00044c-Ap for linux-kernel@vger.kernel.org; Thu, 09 Aug 2018 16:31:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: "Andrey Jr. Melnikov" Subject: Re: [PATCH] netfilter: nf_queue: Replace conntrack entry Date: Thu, 9 Aug 2018 17:09:37 +0300 Lines: 36 Message-ID: References: <20180503140745.26588-1-kristian.evensen@gmail.com> X-Complaints-To: usenet@blaine.gmane.org User-Agent: tin/2.2.1-20140504 ("Tober an Righ") (UNIX) (Linux/4.3.3-bananian (armv7l)) Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In gmane.comp.security.firewalls.netfilter.devel Kristian Evensen wrote: > SKBs are assigned a conntrack entry before being passed to any NFQUEUEs, > and if no entry is found then a new one is created. This behavior causes > problems for some traffic patterns. For example, if two UDP packets > to/from the same host (using the same ports) arrive at the "same" time, > both are assigned a new conntrack entry. After the first packet have > traversed all chains, the conntrack entry will be inserted into the > global table. The second packet will then be dropped during the > insertion step, as an entry for the same flow already exists. One type > of application that frequently generates this traffic pattern, is DNS > resolvers. > This commit introduces a new function that checks, and potentially > replaces, the conntrack entry for any additional "new" SKBs mapping to > an existing flow. While not a perfect solution, there are still > situations where to-be-dropped SKBs can slip through, the situations is > improved considerably. On the routers I have used for testing, packets > belonging to the same UDP flow are let through (when generating the > traffic pattern described above). Without the change in this commit, all > packets except the first one was dropped. > With the change in this commit, a user can implement "perfect" solutions > in user-space. An application can for example keep track of seen UDP > flows, and then only release packets belonging to one flow when the > entry has been created. Without the change, and SKB is stuck with the > original conntrack entry. PING Any progress on this patch? > Signed-off-by: Kristian Evensen > --- > net/netfilter/nfnetlink_queue.c | 68 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 68 insertions(+) [...]