From owner-freebsd-pf@FreeBSD.ORG Tue Jul 24 07:07:11 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CC4106564A for ; Tue, 24 Jul 2012 07:07:11 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id A68C48FC12 for ; Tue, 24 Jul 2012 07:07:09 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q6O771qI022174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2012 09:07:02 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q6O770BQ018935; Tue, 24 Jul 2012 09:07:00 +0200 (MEST) Date: Tue, 24 Jul 2012 09:07:00 +0200 From: Daniel Hartmeier To: Jason Mattax Message-ID: <20120724070700.GF32530@insomnia.benzedrine.cx> References: <20120723100521.GC32530@insomnia.benzedrine.cx> <500E1202.20108@storytotell.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500E1202.20108@storytotell.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: jmattax@clanspum.net, freebsd-pf@freebsd.org Subject: Re: PF suddenly malfunctioned X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:07:11 -0000 What's the client OS? It looks like it might be an incompatibility between the client and the peculiar wikipedia server (or loadbalancer or proxy or whatever there is). Like the GET request gets lost, but the FIN arrives, and the server selectively ACKs the FIN, and the client doesn't retransmit the request. You ran the tcpdump for several seconds after the netcat was started? Maybe repeat it and wait longer, in case the output is buffered. The client should re-transmit. If I tcpdump the same request here, I see the server selectively ACKing FINs even when the plain ACK does so, too. I've never seen this before. Can you try disabling SACK in the client? OpenBSD: sysctl net.inet.tcp.sack=0 FreeBSD: sysctl net.inet.tcp.sack.enable=0 Linux: sysctl net.ipv4.tcp_sack=0 Daniel