Date: Sun, 19 Sep 2004 12:42:30 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Rob <robert@irrelevant.com> Cc: questions@freebsd.org Subject: Re: 4.10, Jails, apache and FIN_WAIT_1 Message-ID: <20040919114230.GD51161@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <6.1.2.0.0.20040918222850.03091b40@albert> References: <6.1.2.0.0.20040918222850.03091b40@albert>
next in thread | previous in thread | raw e-mail | index | archive | help
--0/kgSOzhNoDC5T3a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Sep 18, 2004 at 10:48:15PM +0100, Rob wrote:
> The problem is, I'm getting a lot of stalled connections when accessing t=
he=20
> webserver. running netstat on the host shows e.g.:
>=20
>=20
> tcp4 0 0 jade.http 212.57.246.42.35590 FIN_WAIT_1
> tcp4 0 0 jade.http 212.57.246.42.35585 ESTABLISHED
> tcp4 0 0 jade.http 212.57.246.42.35555 CLOSING
>=20
> This one is me - while this FIN_WAIT_1 is present, I cannot persuade my=
=20
> browser (Opera 7.52 on Windows 2K) to work - it sits with "Sending reques=
t=20
> to www..." in the status line. Pressing refresh does nothing... as soon=
=20
> as the FIN_WAIT_1 vanishes, then everything is OK again, for a few more=
=20
> minutes.
FIN_WAIT_1 means that the server is waiting for a FIN packet from the
client to signal that the TCP connection should be torn down. There's
a few things to check:
i) Do you have 'tcp_extensions=3D"YES"' in /etc/rc.conf -- or the
corresponding net.inet.tcp.rfc1323 sysctl set to 1? That turns
on the RFC1323 extensions. Now, RFC1323 has been around long
enough that just about everything should support it nowadays.
Try toggling the setting -- turning it off may well make things
slower, but "slow" is better than "never". Similarly try
toggling the net.inet.tcp.rfc1644 sysctl from 0 to 1 -- that
enables or disables T/TCP
ii) The TCP_DROP_SYNFIN kernel option (and the corresponding
tcp_drop_synfin rc.conf variable) can cause problems,
particularly with HTTP traffic. As it says in LINT:
#
# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FI=
N. This
# prevents nmap et al. from identifying the TCP/IP stack, but break=
s support
# for RFC1644 extensions and is not recommended for web servers.
#
options TCP_DROP_SYNFIN #drop TCP packets with SYN+=
FIN
iii) Last, but probably most likely: if you're running IPFW or ipf
using dynamic rules, it's possible that the dynamic rules have
been set to time out too quickly during the shutdown phase of
the connection, so the FIN packet from the client is getting
filtered out. Confirm that by turning off the firewall for
testing (so long as you're on a protected private network) or
add a static rule allowing all HTTP traffic between your server
and your test machine.
Tools like tcpdump(1) and etherreal(1) are invaluable when trying to
debug this sort of networking problem: being able to inspeact exactly
what is passing over the wire helps you make sense of a lot of
puzzling failure modes.
Also read the tuning(7) man page for some more detail on what all
those sysctls and things really do, and when you might want to enabe
them.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--0/kgSOzhNoDC5T3a
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQFBTXCmiD657aJF7eIRAkXpAJ0a+oujg+NIKZPPnPmzLV0MmoLCqQCfcy36
bvE8TGKLTgMwUGznpaJdIaQ=
=EqNM
-----END PGP SIGNATURE-----
--0/kgSOzhNoDC5T3a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040919114230.GD51161>