4.10, Jails, apache and FIN_WAIT_1

[Matthew Seaman]

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     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
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040919/71b67fef/attachment.bin