SSL/TCP Connection termination results in RST
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by Chandler Bing on June 5, 2008, 3:06 pm
Please log in for more thread options 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. | ||||||||||||||||
|
Posted by News Reader on June 5, 2008, 8:13 pm
Please log in for more thread options 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 | ||||||||||||||||
|
Posted by Thrill5 on June 7, 2008, 12:59 am
Please log in for more thread options 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? > Chandler Bing wrote:
>> 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 | ||||||||||||||||
|
Posted by Barry Margolin on June 7, 2008, 10:55 am
Please log in for more thread options
> 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. 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). -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** | ||||||||||||||||
|
Posted by Chandler Bing on June 9, 2008, 4:37 pm
Please log in for more thread options >
> > A "FIN" means that the connection is being terminated . =A0 TCP is full
ore
> > duplex, but it's one connection. =A0Once a FIN is sent or received, no m= > > data can be sent or received over that connection.
>
> Incorrect. =A0A FIN means "I'm not going to send any more", it doesn't > mean "I don't want to receive any more". =A0TCP doesn't have any way to > indicate the latter (other than after the fact, by responding to new > data with an RST). > > -- > Barry Margolin, bar...@alum.mit.edu > Arlington, MA > *** PLEASE post questions in newsgroups, not directly to me *** > *** PLEASE don't copy me on replies, I'll read them in the group *** So any good advice that would tell the vendor to STFU? Chandler Bing | ||||||||||||||||
> 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.