| CLOSE | | WAIT-1 |------------------ | WAIT | +---------+ rcv FIN \ +---------+ | rcv ACK of FIN ------- | CLOSE | | -------------- snd ACK | ------- | V x V snd FIN V +---------+ +---------+ +---------+ |FINWAIT-2| | CLOSING | | LAST-ACK| +---------+ +---------+ +---------+ | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN -------------- | Timeout=2MSL -------------- | | ------- x V ------------ x V \ snd ACK +---------+delete TCB +---------+ ------------------------>|TIME WAIT|------------------>| CLOSED | +---------+ +---------+ TCP Connection State Diagram Figure 6. [ref][ref] >> It's not uncommon for some clients (think dialup users running >> Win98), to drop the connection rather rather than close it properly.[/ref] > So the client has time to ACK the server's FIN, but the user closes > the dialup connection, so the application hasn't sent the FIN?[/ref] Your http server answers the HTTP request, and tries to close the connection. It sends a the data, followed by a FIN. It is waiting to receive an ACK of the FIN, and then receive a FIN from the client indicating that the client has no more data to send and is willing to close the connection. -- -Chuck [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => <1111440212.00262725.1111427401@10.7.7.3> [ref] => <1111436621.00262688.1111425002@10.7.7.3> <1111436673.00262701.1111426201@10.7.7.3> <1111440191.00262714.1111426801@10.7.7.3> [htmlstate] => on_nl2br [postusername] => Charles [ip] => cswiger@mac.com [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 4 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) -->| CLOSE | > | WAIT-1 |------------------ | WAIT | > +---------+ rcv FIN \ +---------+ > | rcv ACK of FIN ------- | CLOSE | > | -------------- snd ACK | ------- | > V x V snd FIN V > +---------+ +---------+ +---------+ > |FINWAIT-2| | CLOSING | | LAST-ACK| > +---------+ +---------+ +---------+ > | rcv ACK of FIN | rcv ACK of FIN | > | rcv FIN -------------- | Timeout=2MSL -------------- | > | ------- x V ------------ x V > \ snd ACK +---------+delete TCB +---------+ > ------------------------>|TIME WAIT|------------------>| CLOSED | > +---------+ +---------+ > > TCP Connection State Diagram > Figure 6.[/ref] I've looked at the "Closing a Connection" chapter from the RFC and tried to understand it. The state diagram above shows that from the FINWAIT-2 state there is only one possible way to reach TIME WAIT. So FreeBSD must be using another extension of the RFC-793, when it's sending ACK messages in the FINWAIT-2 state? Wow, I'm confused at this point, I have a linux box here which was the previous webserver, and I can't remember seeing ACK's hitting the firewall logs as it is now with the FreeBSD webserver. Greetings, Robert! [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => <1111443810.00262759.1111431601@10.7.7.3> [ref] => <1111436621.00262688.1111425002@10.7.7.3> <1111436673.00262701.1111426201@10.7.7.3> <1111440191.00262714.1111426801@10.7.7.3> <1111440212.00262725.1111427401@10.7.7.3> [htmlstate] => on_nl2br [postusername] => Robert [ip] => robertgogolok@w [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 5 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) --> FIN_WAIT_2 - FreeBSD
Professional Web Applications Themes

FIN_WAIT_2 - FreeBSD

I have set up a webserver behind a bridged firewall, something like: INTERNET --------- FIREWALL --------- WEBSERVER The webserver is running FreeBSD, and currently I get many FIN_WAIT_2 states: # netstat -n -p tcp | grep FIN_WAIT_2 | wc -l 48 I wonder WHAT is responsible for sending every 5 minutes ACK messages to the clients in FIN_WAIT_2 state? tcp.inet.tcp.always_keepalive seems to be something else # netstat -n -p tcp | grep FIN_WAIT_2 | grep HTTP_CLIENT tcp4 0 0 134.96.240.1.80 HTTP_CLIENT.10228 FIN_WAIT_2 # tcpdump -S -i vr0 dst host HTTP_CLIENT 16:04:12.987415 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack 1760359226 win 0 ...

  1. #1

    Default FIN_WAIT_2

    I have set up a webserver behind a bridged firewall, something like:

    INTERNET --------- FIREWALL --------- WEBSERVER


    The webserver is running FreeBSD, and currently I get many FIN_WAIT_2
    states:
    # netstat -n -p tcp | grep FIN_WAIT_2 | wc -l


    48





    I wonder WHAT is responsible for sending every 5 minutes ACK messages to
    the clients in FIN_WAIT_2 state?
    tcp.inet.tcp.always_keepalive seems to be something else

    # netstat -n -p tcp | grep FIN_WAIT_2 | grep HTTP_CLIENT


    tcp4 0 0 134.96.240.1.80 HTTP_CLIENT.10228
    FIN_WAIT_2








    # tcpdump -S -i vr0 dst host HTTP_CLIENT


    16:04:12.987415 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 0

    16:04:12.987678 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 32900

    16:08:57.944008 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 0

    16:08:57.944300 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 32900

    ..


    ..


    ..


    17:39:12.124577 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 0

    17:39:12.124862 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 32900

    17:43:57.081176 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 0

    17:43:57.081434 IP HTTP_SERVER.http > HTTP_CLIENT.10228: . ack
    1760359226 win 32900


    The bridged firewall seems to block exactly those ACK's.
    The setup is a simple stateful firewall, something like:
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -p tcp -d HTTP_SERVER --dport 80 -j ACCEPT


    Is blocking the ACK messages above somehow harmful?


    Greetings,
    Robert
    Robert Guest

  2. #2

    Default Re: FIN_WAIT_2

    On Mar 21, 2005, at 12:02 PM, Robert Gogolok wrote: 

    The TCP stack wants the remote end to acknowledge the last FIN it sends
    and close the connection cleanly, and there is a timer (2 * MSL?) which
    gets started when a connection moves into the closing stages
    (FIN_WAIT_1, FIN_WAIT_2, LAST_ACK).

    It's not uncommon for some clients (think dialup users running Win98),
    to drop the connection rather rather than close it properly. Your
    system should time out these connections after a while.

    --
    -Chuck

    Charles Guest

  3. #3

    Default Re: FIN_WAIT_2

    Charles Swiger wrote: 

    So FIN_WAIT_2 is the time the server waits to receive the FIN from the
    client, but although it doesn't get this last FIN message yet, it sends
    ACK's for the expected FIN message?

     
    So the client has time to ACK the server's FIN, but the user closes the
    dialup connection, so the application hasn't sent the FIN?

     
    Good decision:-)

    Greetings,
    Robert!

    Robert Guest

  4. #4

    Default Re: FIN_WAIT_2

    On Mar 21, 2005, at 12:35 PM, Robert Gogolok wrote: 
    >
    > So FIN_WAIT_2 is the time the server waits to receive the FIN from the
    > client, but although it doesn't get this last FIN message yet, it
    > sends ACK's for the expected FIN message?[/ref]

    FIN_WAIT_2 is a name describing the state of a TCP connection. It's
    defined in a state diagram in RFC-793. But otherwise, your description
    is pretty good:

    [ ... ]
    | CLOSE +---------+
    | ------- | ESTAB |
    | snd FIN +---------+
    | CLOSE | | rcv FIN
    V ------- | | -------
    +---------+ snd FIN / \ snd ACK +---------+
    | FIN |<----------------- ------------------>| CLOSE |
    | WAIT-1 |------------------ | WAIT |
    +---------+ rcv FIN \ +---------+
    | rcv ACK of FIN ------- | CLOSE |
    | -------------- snd ACK | ------- |
    V x V snd FIN V
    +---------+ +---------+ +---------+
    |FINWAIT-2| | CLOSING | | LAST-ACK|
    +---------+ +---------+ +---------+
    | rcv ACK of FIN | rcv ACK of FIN |
    | rcv FIN -------------- | Timeout=2MSL -------------- |
    | ------- x V ------------ x V
    \ snd ACK +---------+delete TCB +---------+
    ------------------------>|TIME WAIT|------------------>| CLOSED |
    +---------+ +---------+

    TCP Connection State Diagram
    Figure 6.

     
    > So the client has time to ACK the server's FIN, but the user closes
    > the dialup connection, so the application hasn't sent the FIN?[/ref]

    Your http server answers the HTTP request, and tries to close the
    connection. It sends a the data, followed by a FIN. It is waiting to
    receive an ACK of the FIN, and then receive a FIN from the client
    indicating that the client has no more data to send and is willing to
    close the connection.

    --
    -Chuck

    Charles Guest

  5. #5

    Default Re: FIN_WAIT_2

    Charles Swiger wrote: 
    I've looked at the "Closing a Connection" chapter from the RFC and tried
    to understand it. The state diagram above shows that from the FINWAIT-2
    state there is only one possible way to reach TIME WAIT. So FreeBSD must
    be using another extension of the RFC-793, when it's sending ACK
    messages in the FINWAIT-2 state?

    Wow, I'm confused at this point, I have a linux box here which was the
    previous webserver, and I can't remember seeing ACK's hitting the
    firewall logs as it is now with the FreeBSD webserver.

    Greetings,
    Robert!
    Robert Guest

  6. #6

    Default Re: FIN_WAIT_2

    On Mar 21, 2005, at 1:52 PM, Robert Gogolok wrote: 

    That's right.
     

    If the TCP connection is in FIN_WAIT_2, FreeBSD may send out ACKs
    periodicly, trying to nudge the other side to send a FIN to finish
    closing the connection.

    That may be controlled by the keepalive sysctl, but we're starting to
    go beyond my specific knowledge. One of the true FreeBSD network
    wizards like Andre Oppermann might be able to provide more information.
     

    Hmm, it's hard to say. Having a complete tcpdump of a TCP connection
    handy would help, as would making sure that your firewall rules aren't
    doing something to interrupt or block the end of the connection. Are
    you getting any responses back from the clients, or have they
    disappeared?

    --
    -Chuck

    Charles Guest

  7. #7

    Default Re: FIN_WAIT_2

    Charles Swiger wrote: 
    This is indeed the case (when I interpret the tcpdump output correct):

    21:19:20.139373 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 0
    21:19:20.139543 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 65535
    21:24:05.098980 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 0
    21:24:05.099151 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 65535
    ..
    .. AND SO ON :-)
    ..
    22:11:34.665056 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 0
    22:11:34.665225 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 65535
    22:16:19.621661 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 0
    22:16:19.621824 IP HTTP_SERVER.http > HTTP_CLIENT.63131: . ack
    2918467318 win 65535


    HTTP_SERVER.http > HTTP_CLIENT.63131 is in FIN_WAIT_2 state.
    After the last line it stopped and go away from FIN_WAIT_2 as expteced
    (timeout...).

    And the firewall rejects/drops exactly those packages.
    The client is not responding.


    Greetings,
    Robert!
    Robert Guest

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139