From owner-freebsd-net@freebsd.org Sat Jan 21 04:21:19 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADE71CBABE1 for ; Sat, 21 Jan 2017 04:21:19 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 95E1D1C9B; Sat, 21 Jan 2017 04:21:19 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 722C6124AEA4; Fri, 20 Jan 2017 20:21:18 -0800 (PST) To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= cc: FreeBSD Net , Alan Somers Subject: Re: pf & NAT issue In-reply-to: Your message of "Fri, 20 Jan 2017 14:22:41 PST." References: <20170120083555.ACCF9124AEA4@mail.bitblocks.com> <7C29D00C-94C0-4550-B1B2-CE307482B544@FreeBSD.org> <20170120203106.CD2C8124AEA4@mail.bitblocks.com> <20170120205933.8948A124AEA3@mail.bitblocks.com> <20170120211734.488D8124AEA5@mail.bitblocks.com> Comments: In-reply-to =?UTF-8?Q?Ermal_Lu=C3=A7i?= message dated "Fri, 20 Jan 2017 14:22:41 -0800." Date: Fri, 20 Jan 2017 20:21:18 -0800 From: Bakul Shah Message-Id: <20170121042118.722C6124AEA4@mail.bitblocks.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 04:21:19 -0000 I finally had some time to look at the sources & noticed /sys/netpfil/pf/pf.c:pf_purge_thread now runs 10 times a second instead of once a second, which gave me the idea of increasing "interval" timeout by a factor of 10 and this seems to have mostly fixed the problem. But I don't know where the actual problem is. The logic is too complicated to understand in a few minutes so I didn't try to find the root cause at the moment. [But I don't understand why pf times out normal connections. Long lasting idle connections are perfectly fine. And fragment GC should not be coupled with connection state expiry] Many thanks for various suggestions as that forced me think :-) Bakul