TCP RST Question (OT)

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

  1. amyl

    amyl 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

    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.

    amyl, Oct 15, 2008
    1. Advertisements

  2. ---> 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?
    ---> I assume it's trying with the same source port?
    ---> Client finally gives up and tries a new 3-way handshake?
    ---> 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".
    ---> Yes, as mentioned above if the port doesn't have a listener available.
    ---> 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.
    ---> 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.).
    fugettaboutit, Oct 15, 2008
    1. Advertisements

  3. amyl

    amyl Guest

    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.

    amyl, Oct 15, 2008
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.