Date: Tue, 24 Jul 2012 09:07:00 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Jason Mattax <jmattax@storytotell.org> Cc: jmattax@clanspum.net, freebsd-pf@freebsd.org Subject: Re: PF suddenly malfunctioned Message-ID: <20120724070700.GF32530@insomnia.benzedrine.cx> In-Reply-To: <500E1202.20108@storytotell.org> References: <effb611b289f2b14d345c1cd63c9828a.squirrel@mail.clanspum.net> <20120723100521.GC32530@insomnia.benzedrine.cx> <500E1202.20108@storytotell.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120724070700.GF32530>