1. Home
  2. Cisco Systems
  3. TCP RST Question (OT)

TCP RST Question (OT)

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.

Reply to
amyl
Loading thread data ...

---> 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.).

Reply to
fugettaboutit

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.

Reply to
amyl

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.