Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Reading through the following passage from Wiki on TCP Reset I have a question:

"When used as designed this can be a useful tool. One common application is the scenario where a computer (we'll call it computer A) crashes while a TCP connection is in progress. The computer on the other end (computer B) will continue to send TCP packets since it does not know computer A has crashed. When computer A reboots, it will then receive packets from the old pre-crash connection. Computer A has no context for these packets and no way of knowing what to do with them, so it might send a TCP reset to the sender of the packets - computer B. This reset lets computer B know that the connection is no longer working. The user on computer B can now try another connection or take other action."

In the above case what would Seq and Ack numbers be? Since computer A has no context of the previous connection on what basis would reset happen and how can B ascertain that the Reset is for the actual connection that it thinks is still maintained? Why can't it be for any other connection?

share|improve this question

migrated from Feb 27 '12 at 23:15

This question came from our site for information security professionals.

The key part of your information above is:

When computer A reboots, it will then receive packets from the old pre-crash connection. 

It will get the sequence and ack numbers if/when it receives these packets it will send a RST packet with the appropriate sequence and ack numbers. If it does not see the packets then it will not send any RST packets.

share|improve this answer

Your Answer


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