dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed


Washington, DC

4 edits

[Speed] There are good resets and there are bad resets...

Please bear with me here. For the sake of my own understanding and others, I am going to summarize what I have learned from FunChords explanations posted at »How to test how many connections are being reset by RST pack .
Please note that I am summarizing the information and avoiding comment on political issues.

Regarding Resets, there are good resets and there are bad resets.

Good Resets: In any normal network transaction, there are several steps that received by the sender and then ACKnowledged by the receiver. Each received SEQuence from the sender has a number and each ACKnowledge from the receiver is returned with that same number. Along with the received SEQuence is included a command to be executed, such as SYNchronize at the beginning and Final (FIN) at the end. Often normal network transactions finish with a Reset (RST) command.

Bad Resets: Some programs or devices are used to manage traffic for various purposes. High-end corporate wan optimizers and routers actually use store and forward methods to requeue packets in such a way to avoid congestion. These do not present a problem.

However other programs or devices take advantage of the network protocols to send a fake reset command to break the transaction. This causes the transaction to be requeued later, allowing other traffic to proceed. It can also cause transaction failure if it cannot be requeued.

How do we determine what are bad resets?

Remember that normal transactions end with a reset. The percentage of resets will be higher for short transactions and lower for long transactions. The resets will come from you and everyone else you are connected to. For this reason, NetStat is not an effective means to detect bad resets. It shows all resets and at best only indicates the percentage of short or long transactions. The higher the percentage, the more short transaction you are processing.

To better understand the number of resets you are concerned about, you need to view only incoming resets to the port that you are concerned with. Using Ethereal or Wireshark and a filter string you can see this.

"( ip.src != your.ip.addr.ess ) and ( tcp.flags.reset == 1) and (tcp.seq > 1) and ( tcp.ack > 1)and (tcp.dstport == yourport)"

This string looks for incoming packets with the reset flag set and have passed the first transaction sequence.
Turn on Name Resolution so you can see the source domain.

In my case, I only see about three resets in a 10 minute period so I am not concerned. However if you are seeing many resets, continue on.

Right click on a reset and select "Follow TCP stream". This will create a new filter to display the whole transaction. The "Follow Conversation" option will also give you a similar display.

Starting from the beginning, look at the SEQ and ACK numbers for each transaction. The SEQ number will be sent back as the ACK number in the next transaction. The last transaction will have a reset (RST) command. After viewing a number of these, you will recognize the normal transaction pattern.

In a bad transaction, a reset (RST) with the correct sequence is sent shortly after the data transmission has started. This stops the transmission and then a second reset (RST) with an out of sequence number is also sent.

A good example is posted at »torrentfreak.com/images/comcast-rst1.txt

What can I do about bad resets?

Understand that you cannot easily verify the source of these resets: They can come from anyone who can view and transmit on the network. Usually it is from a network device or program in between the sender and the receiver. If they are forged, they can be made to look like anyone, even you. Some sources can be low-end traffic shapers, network blocking programs, hacker programs, or the actual sender may have a problem with their client.

Some solutions, in order of difficulty;

Do not proceed to Step 5 until you have completely tested 1,2,3 & 4!

1) Turn off any other programs on your machine or home network. If you observe an improvement, turn them back on one at a time and note which one causes a drop in performance.

2) Set your client to use random port assignments. This will bypass some (not all) port filtering.

3) Change your client to one that includes encryption, it should also allow connection to non-encrypted clients.

4) Change your online behaviour. Some systems are rule based and others are profile based. With some time and observation, you can determine what works for you.

Do not run full stream 24by7. Use your scheduler to break up sessions to different times on different days. Set your bandwidth limits to not exceed 70% and then begin lowering them by 10% until the resets go away.

5) Get a VPN service, some providers are quite reasonably priced. However some sites will not be accessible if you are seen as an anonymous connection. Also, there are reports of VPN's being blocked so this may not work either.

6) Change your ISP. However this will only fix the problem at your end. It will not help if someone else has a bad connection.

7) Change your level of service. This is very expensive and unless you have a justifiable business reason, not recommended.

I hope this has been helpful.


John M. Wilson