TCP RST Question (OT)

Discussion in 'Cisco' started by amyl@paxemail.com, Oct 15, 2008.

  1. Guest

    Sorry if this is a bit off topic for the group.

    I have an issue that I am troubleshooting where a vendor indicates
    their box is losing connectivity between the client and server which
    is causing application issues.

    I SPAN'ed the port (Cisco 2960) of the client and am going through the
    captures and I noticed something that struck me as odd.

    Client issues a FIN, ACK
    Server issues a FIN, ACK

    However, after those FIN's I never see any ACK's from either side.

    At this point the client starts attempting to reestablish the
    connection (multiple SYN attempts) with no response from the server.

    After approx 10 attempts (20 seconds) the client issues a RST with an
    ACK. This packets SEQ=0, ACK=1

    If there is no associated connection so how can it issue the RST with
    an ACK?

    After it issues this RST packet it immediately establishes the
    connection.

    Questions:
    1.) Is it normal to see a RST packet not associated with an active
    connection have the ACK flag set?
    2.) Speculation: because each side never really acknowledged the
    connection close I suspect the connection may still be open on the
    server end and the RST packet closed it on the server allowing it to
    be recreated?

    Any thoughts regarding this? Sorry about the OT nature of this.

    Amy.
     
    , Oct 15, 2008
    #1
    1. Advertising

  2. wrote:
    > Sorry if this is a bit off topic for the group.
    >
    > I have an issue that I am troubleshooting where a vendor indicates
    > their box is losing connectivity between the client and server which
    > is causing application issues.
    >
    > I SPAN'ed the port (Cisco 2960) of the client and am going through the
    > captures and I noticed something that struck me as odd.
    >
    > Client issues a FIN, ACK
    > Server issues a FIN, ACK
    >


    ---> Is this a Microsoft IIS box? Back in the day, they used to play
    games with keeping the TCP connection "half open" so that subsequent
    requests by the client didn't go through the normal 3-way handshake.
    This gave the illusion of increased performance from IIS. I also believe
    Apache implements a LINGER function for TCP stack connection close()
    calls. I'm not a programmer, but I believe this is possible due to less
    overhead for Apache to manage when the close() call is implemented by
    the TCP stack. I believe the FIN_WAIT timer then "manages" the final
    closure. Check my theory, but I believe one of these cases may explain
    why you're not seeing the final ACK. Curious...if you watch the flow for
    a while, does you eventually see ACKs between the client and server?

    > However, after those FIN's I never see any ACK's from either side.
    >
    > At this point the client starts attempting to reestablish the
    > connection (multiple SYN attempts) with no response from the server.
    >


    ---> I assume it's trying with the same source port?

    > After approx 10 attempts (20 seconds) the client issues a RST with an
    > ACK. This packets SEQ=0, ACK=1
    >


    ---> Client finally gives up and tries a new 3-way handshake?

    > If there is no associated connection so how can it issue the RST with
    > an ACK?
    >


    ---> One possibility, Per RFC, the TCP stack will respond with an RST if
    the service is unavailable (no listener). I suspect it's from my above
    comment: the connection is still "half open".

    > After it issues this RST packet it immediately establishes the
    > connection.
    >
    > Questions:
    > 1.) Is it normal to see a RST packet not associated with an active
    > connection have the ACK flag set?


    ---> Yes, as mentioned above if the port doesn't have a listener available.

    > 2.) Speculation: because each side never really acknowledged the
    > connection close I suspect the connection may still be open on the
    > server end and the RST packet closed it on the server allowing it to
    > be recreated?
    >


    ---> My guess is the client connection went into FIN_WAIT_1 state. From
    the server's perspective, the connection to the client isn't closed
    until FIN_WAIT_2. That won't happen until the (FIN, ACK) is ACK'd.

    > Any thoughts regarding this? Sorry about the OT nature of this.
    >


    ---> It sounds like a mismatch in the way the client (Microsoft?)
    handles RSTs from the server (non-Microsoft?). Can you elaborate on the
    scenario just a bit more? Perhaps the actual connection tear-down
    scenario (who's issues the tear-down first, etc.).

    > Amy.
     
    fugettaboutit, Oct 15, 2008
    #2
    1. Advertising

  3. Guest

    On Oct 15, 3:43 pm, fugettaboutit <> wrote:
    > wrote:
    > > Sorry if this is a bit off topic for the group.

    >
    > > I have an issue that I am troubleshooting where a vendor indicates
    > > their box is losing connectivity between the client and server which
    > > is causing application issues.

    >
    > > I SPAN'ed the port (Cisco 2960) of the client and am going through the
    > > captures and I noticed something that struck me as odd.

    >
    > > Client issues a FIN, ACK
    > > Server issues a FIN, ACK

    >
    > ---> Is this a Microsoft IIS box? Back in the day, they used to play
    > games with keeping the TCP connection "half open" so that subsequent
    > requests by the client didn't go through the normal 3-way handshake.
    > This gave the illusion of increased performance from IIS. I also believe
    > Apache implements a LINGER function for TCP stack connection close()
    > calls. I'm not a programmer, but I believe this is possible due to less
    > overhead for Apache to manage when the close() call is implemented by
    > the TCP stack. I believe the FIN_WAIT timer then "manages" the final
    > closure. Check my theory, but I believe one of these cases may explain
    > why you're not seeing the final ACK. Curious...if you watch the flow for
    > a while, does you eventually see ACKs between the client and server?
    >
    > > However, after those FIN's I never see any ACK's from either side.

    >
    > > At this point the client starts attempting to reestablish the
    > > connection (multiple SYN attempts) with no response from the server.

    >
    > ---> I assume it's trying with the same source port?
    >
    > > After approx 10 attempts (20 seconds) the client issues a RST with an
    > > ACK. This packets SEQ=0, ACK=1

    >
    > ---> Client finally gives up and tries a new 3-way handshake?
    >
    > > If there is no associated connection so how can it issue the RST with
    > > an ACK?

    >
    > ---> One possibility, Per RFC, the TCP stack will respond with an RST if
    > the service is unavailable (no listener). I suspect it's from my above
    > comment: the connection is still "half open".
    >
    > > After it issues this RST packet it immediately establishes the
    > > connection.

    >
    > > Questions:
    > > 1.) Is it normal to see a RST packet not associated with an active
    > > connection have the ACK flag set?

    >
    > ---> Yes, as mentioned above if the port doesn't have a listener available.
    >
    > > 2.) Speculation: because each side never really acknowledged the
    > > connection close I suspect the connection may still be open on the
    > > server end and the RST packet closed it on the server allowing it to
    > > be recreated?

    >
    > ---> My guess is the client connection went into FIN_WAIT_1 state. From
    > the server's perspective, the connection to the client isn't closed
    > until FIN_WAIT_2. That won't happen until the (FIN, ACK) is ACK'd.
    >
    > > Any thoughts regarding this? Sorry about the OT nature of this.

    >
    > ---> It sounds like a mismatch in the way the client (Microsoft?)
    > handles RSTs from the server (non-Microsoft?). Can you elaborate on the
    > scenario just a bit more? Perhaps the actual connection tear-down
    > scenario (who's issues the tear-down first, etc.).
    >
    > > Amy.


    > ---> It sounds like a mismatch in the way the client (Microsoft?)
    > handles RSTs from the server (non-Microsoft?). Can you elaborate on the
    > scenario just a bit more? Perhaps the actual connection tear-down
    > scenario (who's issues the tear-down first, etc.).


    The actual boxes are appliances running a custom version of some *nix
    flavor. The connection tear down is initiated by the client. I have
    requested from the vendor to explain why the client is requesting the
    connection termination. The odd thing from the vendor is that it
    should not be requesting the connection close.

    However, I think you hit the head on the nail regarding they are
    leaving the connection half open for some reason, but I wont get more
    info regarding that until their developers respond to my findings.

    Amy.
     
    , Oct 15, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eggert Ehmke

    strange tcp.rst resets on vip

    Eggert Ehmke, Apr 12, 2006, in forum: Cisco
    Replies:
    0
    Views:
    511
    Eggert Ehmke
    Apr 12, 2006
  2. Matthias Scheler

    Sending RST packets

    Matthias Scheler, Dec 8, 2006, in forum: Cisco
    Replies:
    1
    Views:
    1,291
    Martin Turba
    Dec 9, 2006
  3. Andy Lawson
    Replies:
    13
    Views:
    600
    Matt B
    Oct 6, 2003
  4. Chandler Bing
    Replies:
    5
    Views:
    1,258
  5. mjb

    Tcp [rst]

    mjb, Aug 14, 2008, in forum: Computer Information
    Replies:
    0
    Views:
    919
Loading...

Share This Page