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 the > webserver. running netstat on the host shows e.g.: > > > tcp4 0 0 jade.http 188.8.131.52.35590 FIN_WAIT_1 > tcp4 0 0 jade.http 184.108.40.206.35585 ESTABLISHED > tcp4 0 0 jade.http 220.127.116.11.35555 CLOSING > > This one is me - while this FIN_WAIT_1 is present, I cannot persuade my > browser (Opera 7.52 on Windows 2K) to work - it sits with "Sending request > to www..." in the status line. Pressing refresh does nothing... as soon > as the FIN_WAIT_1 vanishes, then everything is OK again, for a few more > 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="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+FIN. This # prevents nmap et al. from identifying the TCP/IP stack, but breaks 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 -- 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
Description: PGP signature