Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've been reading about the TCP protocol recently because I was a little curious about how and why certain flags were used.

In the information I found it talks about a normal close TCP FIN should be used to close a connection but then it also talks about TCP RSET can be used for an abortive close on an active connection.

My question is, why would one use a RSET to about close an active connection over using TCP FIN?

(referring to an active connection as a connection where both endpoints sent and received data after the standard 3 way handshack. I know a RSET can be used by the server when a client sends SYN for a server port that is not listening)

share|improve this question
add comment

3 Answers

You wouldn't normally see a TCP RST. I suppose an application at layer 7 aborting might generate a RST, but I think you'll find that a RST is most often generated by a firewall between the two hosts. Here's a list of possible reasons from the TCP/IP guide:

Receipt of any TCP segment from any device with which the device receiving the segment does not currently have a connection (other than a SYN requesting a new connection).

Receipt of a message with an invalid or incorrect Sequence Number or Acknowledgment Number field, indicating the message may belong to a prior connection or is spurious in some other way.

Receipt of a SYN message on a port where there is no process listening for connections.

share|improve this answer
    
+1 for that. A common application-level RST is when the connecting IP is in hosts.deny. IME, though, it's fairly common for applications to RST when something 'bad' has happened and they want to say "I'm not talking to you any more. Go away." –  SmallClanger Mar 2 '11 at 16:32
    
@SmallClanger, if an application were to receive a RST because of something "bad" should it handle that differently then say a FIN? As in, should it consider a FIN as just a regular disconnect and a RST as "Oh, maybe I'm doing something wrong"? –  Phillip Mar 4 '11 at 5:17
    
I would assume that a RST would be considered a hostile disconnect vs. a FIN. Like firing someone at work vs. them leaving because the contracted project is complete. –  Phillip Mar 4 '11 at 5:28
    
That's a good analogy for it. –  joeqwerty Mar 4 '11 at 11:51
add comment

Some webservers use RST instead of FIN to close (persistent) connections. This is seen as an "optimisation", because it avoids the "half-closed" state and sidesteps some of the issues with missed FIN packets (any further transmission will just produce another RST), that would otherwise require state to be remembered (2xMaximum segment time IIRC) for longer on the server side.

See: this paper and wikipedia on connection termination. (I'll try and dig out some more interesting references too).

You might also see RST if application with the socket crashed (segfault?), host rebooted, or NAT table entries timed out before the connection itself did!

share|improve this answer
    
If I may ask, since you brought it up with host reboot, during a crash, how does one end (stable) find out the the other end (unstable) crashed? If the application doesn't send anything I would assume it can translate that as just "no data to receive" vs. translate a crash but how does it do that exactly? –  Phillip Mar 4 '11 at 5:25
    
it won't notice (usually) until the remaining end tries to send something and it either a) times out after multiple retransmissions without a corresponding ACK or b) sends something to a host that wasn't expecting it and gets and RST back. –  Flexo Mar 4 '11 at 9:48
add comment

This is an edge case but I find it interesting:

Some filtering software like web sense (ab)uses RST packets. What happens is that instead of websense sitting between all the traffic it sniffs traffic off the wire. If it sees a blocked site it spoofs an RST packet to the client (and I think maybe the server as well).

This is more of a clever trick then it is an intended use though.

share|improve this answer
    
Is that reliable? Doesn't it require sequence number prediction? –  Flexo Mar 2 '11 at 16:41
    
@Alan: I never looked at any dumps, this was just explained to me by an engineer there. However since it would sit on the lan I imagine it it is pretty easy to win the race for something being accessed over the WAN. I don't think prediction would be a problem when you can see both sides of the conversation. –  Kyle Brandt Mar 2 '11 at 16:46
    
Ah yes, I guess doing it en-route is much easier than the general case. –  Flexo Mar 2 '11 at 16:52
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.