Date: Tue, 24 Jul 2012 22:37:52 +0100 From: Greg Hennessy <Greg.Hennessy@nviz.net> To: Jason Mattax <jmattax@storytotell.org> Cc: "jmattax@clanspum.net" <jmattax@clanspum.net>, "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: RE: PF suddenly malfunctioned Message-ID: <9EB23F6C23A8B6488E8BCC92A48E83264BB4D27913@PEMEXMBXVS04.jellyfishnet.co.uk.local> In-Reply-To: <500EB432.6050803@storytotell.org> References: <effb611b289f2b14d345c1cd63c9828a.squirrel@mail.clanspum.net> <20120723100521.GC32530@insomnia.benzedrine.cx> <500E1202.20108@storytotell.org> <20120724070700.GF32530@insomnia.benzedrine.cx> <500EB432.6050803@storytotell.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20 > On 07/24/2012 01:07 AM, Daniel Hartmeier wrote: > > What's the client OS? > > > The client OS for this test is Ubuntu 12.04 LTS >=20 > jmattax@chani:~/pf_debugging$ uname -a > Linux chani 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 16:26:01 UTC 2012 > i686 i686 i386 GNU/Linux >=20 > > 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. > > >=20 > I initially ran the tcpdumps until the client had nc return and give me a= new > prompt in my shell (that took maybe a second). I just repeated it as abov= e > letting the tcpdumps run longer and it captured the same number of packet= s. >=20 Hi Jason,=20 Try mss clamping the outside interface using the relevant 'scrub' option to= rule out a Path MTU issue.=20 Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9EB23F6C23A8B6488E8BCC92A48E83264BB4D27913>