Re: 4.10, Jails, apache and FIN_WAIT_1

From: Matthew Seaman (m.seaman_at_infracaninophile.co.uk)
Date: 09/19/04

  • Next message: Matthew Seaman: "Re: core dump with portupgrade" 
    Date: Sun, 19 Sep 2004 12:42:30 +0100
To: Rob <robert@irrelevant.com>

    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 message: Matthew Seaman: "Re: core dump with portupgrade"