My company is working with VeriFone and TSys to isolate issues we've seen with SSL transactions. We're being told that once one side sends a FIN, that terminates the entire conversation and indeed the other side still has data to send and when it performs a PSH, it's ignored and ultimately the connection is RST. I'm being told by both sides that this is normal. I don't believe it is.
I have packet captures, but I'm not sure how to post them or share them out.
My belief is as follows:
A TCP connection is duplex; with an independent stream in each direction. When one side has no more data to send it can close its half of the duplex connection.
When a Sender finishes sending its data, it waits for an ACK from the Receiver, and then may send a FIN segment to close its half of the connection. The Receiver would ACK the FIN segment, and inform the local application that no more data will be forthcoming. The Receiver would not respond immediately with a FIN segment, but would instead wait for a response from the local application. Prior to receiving a response from the local application, data should be able to flow on the non-closed side of the duplex connection, if there is data to send.
When the local application responds with the authorization to shutdown the 2nd half of the duplex connection, a FIN segment is sent to the other side. That FIN segment will be ACK'd ending the four-way handshake.
I think a RST is used to close/abort transfers in both directions, and occurs under abnormal conditions.
That's about all I can offer.
Best Regards, News Reader
A "FIN" means that the connection is being terminated . TCP is full duplex, but it's one connection. Once a FIN is sent or received, no more data can be sent or received over that connection. From a protocol level, the behavior is normal, but the question should be why is the FIN being sent in the first place? If the connection is being terminated by one side, and the other needs to send more data, why isn't that side initiating another TCP connection?
Incorrect. A FIN means "I'm not going to send any more", it doesn't mean "I don't want to receive any more". TCP doesn't have any way to indicate the latter (other than after the fact, by responding to new data with an RST).
So any good advice that would tell the vendor to STFU?
Chandler Bing
I've seen this behavior before. What I saw was that the side sending the FIN is not waiting for the other side to respond, it is just closing the socket and terminating the process. The OS then cleans up the socket structures. When the OS gets a packet for that connection it no longer has any place to send it and so responds with an RST.
Basically, it is an application error and needs to be corrected in the application. Either the application should not close the connection until it is sure that the remote side is done sending data (some kind of indication at the application protocol layer) or it should call shutdown, indicating that it is done sending data and then loop receiving data until it gets an indictaion that the remote side has sent a FIN. Then it can close the socket and terminate the process.
So any good advice that would tell the vendor to STFU?
Chandler Bing
As I look more at the traces, it appears the VeriFone terminal (client) does a TCP close. It does not do an SSL close_notify, as it should. The server attempts to push some final TCP data, but is ignored, it finally does its own encrypted alert, which is message type 21. I'm not sure, but I think that's decryption_failed, but that doesn't seem right, since it's a TLS message and this is SSL. After numerous attempts it finally does a close_notify & FIN which prompts the VeriFone terminal to do a RST.
It appears that the VeriFone terminal is doing a TCP close, without closing the SSL session and then doesn't allow the other side to close it's TCP session. I've since found out that the VeriFone terminal runs a firewall made by McAfee. I wonder if it's their application, IP Stack, or firewall that's causing all these problems.
Chandler Bing
I have heard that it is common for tcp applications to simply send a FIN and terminate or even to just terminate. As already described this results in a RST being sent by the end that no longer has the socket open in the event that further packets arrive.
This is NOT 'correct' behaviour but of course the end result is the one that the terminating application is aiming for so no one really cares.
I have seen FIN .... RST in many many packet traces but have never properly bored in to try to explain the behaviour in the detail that you seem to require.
It is very common.
Hope this helps a little.
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.