Screamer - TCP RST

W

wow4life

Senior Member
Joined
Jun 23, 2008
Messages
593
Reaction score
0
Location
Back on planet Earth
I have been monitoring my network traffic closely using a packet sniffer and noticed that I am receiving a connection reset (TCP RST) every so often.

Not sure why the server is resetting my connection but I guess it has to do with a synchronization issue.

Will continue to investigate but was curious if anyone else noticed this.
 
wow4life said:
I have been monitoring my network traffic closely using a packet sniffer and noticed that I am receiving a connection reset (TCP RST) every so often.

Not sure why the server is resetting my connection but I guess it has to do with a synchronization issue.

Will continue to investigate but was curious if anyone else noticed this.
Click to expand...

I have noticed that. Also happens with UDP connections.
 
Normally this isn't an issue and certainly part of the TCP function as it is meant to initiate a recovery.

However, with online gaming or any high interactive application it results in a disconnect from the server.
 
wow4life said:
I have been monitoring my network traffic closely using a packet sniffer and noticed that I am receiving a connection reset (TCP RST) every so often.

Not sure why the server is resetting my connection but I guess it has to do with a synchronization issue.

Will continue to investigate but was curious if anyone else noticed this.
Click to expand...

I get a connection reset every now and then aswell.
VERY irritating when one tries to remote onto a client's machine.
:mad:
 
Hi Guys

I'll get the techs to check this tomorrow.
 
Last night I received approx 6 TCP Resets in a 3 hour period :/

It could be that the server is resetting due to lost packets - however my pings didn't show an unusually high amount of lost packets - definitely not worse than before.
 
"RST packets are a sign that the TCP connections are half open. One station or the other stopped sending information or ACKs for some reason."

So any connection problems (signal, upstream etc) would eventually result in the RST flag being set.

It is my hypothesis that the maximum number of retries is being exceeded due to a general network problem. I will increase the number of tcp retries as see if this changes the behaviour.
 
Analysing a stream doesn't reveal the reason - as you can see below the entire conversation is normal - right up until the receipt of the reset.

What is confusing is why the server is sending the reset. I can duplicate this with several different servers or proxies.

No. Time Source Destination Protocol Info
7117 15:44:40.469143 192.168.2.32 94.23.194.227 TCP mxomss > bmap [PSH, ACK] Seq=67920 Ack=270790 Win=65083 Len=60
7118 15:44:40.469807 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=270790 Ack=67560 Win=16080 Len=76
7119 15:44:40.519812 192.168.2.32 94.23.194.227 TCP mxomss > bmap [PSH, ACK] Seq=67980 Ack=270866 Win=65007 Len=60
7120 15:44:40.525075 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=270866 Ack=67620 Win=16080 Len=36
7121 15:44:40.552842 192.168.2.32 94.23.194.227 TCP mxomss > bmap [PSH, ACK] Seq=68040 Ack=270902 Win=64971 Len=60
7122 15:44:40.609593 94.23.194.227 192.168.2.32 TCP bmap > mxomss [ACK] Seq=270902 Ack=67740 Win=16080 Len=0
7123 15:44:40.669601 94.23.194.227 192.168.2.32 TCP bmap > mxomss [ACK] Seq=270902 Ack=67860 Win=16080 Len=0
7124 15:44:40.714608 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=270902 Ack=67980 Win=16080 Len=36
7125 15:44:40.799676 94.23.194.227 192.168.2.32 TCP bmap > mxomss [ACK] Seq=270938 Ack=68100 Win=16080 Len=0
7126 15:44:40.819568 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=270938 Ack=68100 Win=16080 Len=60
7127 15:44:40.819618 192.168.2.32 94.23.194.227 TCP mxomss > bmap [ACK] Seq=68100 Ack=270998 Win=64875 Len=0
7128 15:44:40.889726 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=270998 Ack=68100 Win=16080 Len=60
7129 15:44:41.120533 192.168.2.32 94.23.194.227 TCP mxomss > bmap [PSH, ACK] Seq=68100 Ack=271058 Win=64815 Len=60
7130 15:44:41.287506 192.168.2.32 94.23.194.227 TCP mxomss > bmap [PSH, ACK] Seq=68160 Ack=271058 Win=64815 Len=60
7131 15:44:41.399625 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=271058 Ack=68160 Win=16080 Len=28
7132 15:44:41.599713 94.23.194.227 192.168.2.32 TCP bmap > mxomss [ACK] Seq=271086 Ack=68220 Win=16080 Len=0
7133 15:44:41.649661 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=271086 Ack=68220 Win=16080 Len=76
7134 15:44:41.649706 192.168.2.32 94.23.194.227 TCP mxomss > bmap [ACK] Seq=68220 Ack=271162 Win=64711 Len=0
7136 15:44:41.679600 94.23.194.227 192.168.2.32 TCP bmap > mxomss [PSH, ACK] Seq=271162 Ack=68220 Win=16080 Len=156
7137 15:44:41.914845 192.168.2.32 94.23.194.227 TCP mxomss > bmap [ACK] Seq=68220 Ack=271318 Win=64555 Len=0
7138 15:44:42.159607 94.23.194.227 192.168.2.32 TCP bmap > mxomss [RST] Seq=271318 Win=0 Len=0
 
I removed all the proxies so look under the covers (as far as I can go) and noticed similar behaviour - communication looks fine.

Only possible problem prior to the reset is that there seem to be a large number of ACKs coming from the server, which could indicate that they didn't get through earlier but this doesn't make sense as there are no requests for retransmission (unless I am not seeing them).

Furthermore, the normal communication seems to display this behaviour therefore I assume it isn't a problem.

Then ... I get a RST.

No. Time Source Destination Protocol Info
51541 23:50:22.204213 192.168.2.32 213.248.123.58 TCP directplay > blizwow [ACK] Seq=213454 Ack=695183 Win=64540 Len=0
51542 23:50:22.213946 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695183 Ack=213244 Win=14672 Len=0
51543 23:50:22.328640 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695183 Ack=213286 Win=14672 Len=0
51544 23:50:22.333735 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695183 Ack=213328 Win=14672 Len=0
51545 23:50:22.363750 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695183 Ack=213370 Win=14672 Len=0
51546 23:50:22.393714 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695183 Ack=213412 Win=14672 Len=0
51547 23:50:22.463819 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695183 Ack=213454 Win=14672 Len=0
51548 23:50:22.463967 213.248.123.58 192.168.2.32 TCP [TCP segment of a reassembled PDU]
51549 23:50:22.463990 192.168.2.32 213.248.123.58 TCP directplay > blizwow [ACK] Seq=213454 Ack=695294 Win=64429 Len=0
51550 23:50:22.700733 192.168.2.32 213.248.123.58 TCP [TCP segment of a reassembled PDU]
51551 23:50:22.833610 213.248.123.58 192.168.2.32 TCP [TCP segment of a reassembled PDU]
51552 23:50:22.833665 192.168.2.32 213.248.123.58 TCP directplay > blizwow [ACK] Seq=213496 Ack=695348 Win=64375 Len=0
51553 23:50:23.033743 213.248.123.58 192.168.2.32 TCP blizwow > directplay [ACK] Seq=695348 Ack=213496 Win=14672 Len=0
51554 23:50:23.123800 213.248.123.58 192.168.2.32 TCP [TCP segment of a reassembled PDU]
51555 23:50:23.123915 192.168.2.32 213.248.123.58 TCP directplay > blizwow [ACK] Seq=213496 Ack=695410 Win=64313 Len=0
51556 23:50:23.201780 192.168.2.32 213.248.123.58 TCP [TCP segment of a reassembled PDU]
51557 23:50:23.418496 213.248.123.58 192.168.2.32 TCP blizwow > directplay [RST] Seq=695410 Win=0 Len=0
 
wow4life said:
My current suspicion is that it is a NAT issue ... the investigation continues
Click to expand...

Well, dunno if this is related to your findings;

I would be connected, yet I won't be able to ping anything beyond 172.17.0.1 (or very similar address).

My tower I connect to pings at roughly 60ms. The telephone gateway works, so it must be a DNS or other prob.
:confused:

It may very well be a NAT issue - thanks wow4life !!!!!
:thumbsup to you!!!!
 
An update:

If I eliminate my router and use a proxy in London then the situation is a lot better. The only time I disconnect now is when I receive a double RST (see below) i.e. same sequence.

This certainly feels like an address translation issue but not sure.

No. Time Source Destination Protocol Info
21859 23:16:41.689353 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=2621993 Win=0 Len=0
23355 23:17:22.521105 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=2751453 Win=0 Len=0
29364 23:19:45.615874 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=3363225 Win=0 Len=0
48018 23:27:25.483124 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=5736341 Win=0 Len=0
55489 23:30:04.026500 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=6816233 Win=0 Len=0
87590 23:41:35.081860 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=11055285 Win=0 Len=0
87592 23:41:35.166996 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=11055557 Win=0 Len=0
87594 23:41:35.256979 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=11055693 Win=0 Len=0
87595 23:41:35.266848 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=11055694 Win=0 Len=0
87597 23:41:35.276848 78.129.220.51 10.0.64.200 TCP bmap > jtag-server [RST] Seq=11055694 Win=0 Len=0
100393 23:47:45.085351 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=1665378 Win=0 Len=0
101847 23:48:17.423410 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=1841374 Win=0 Len=0
117851 23:54:43.080153 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=3578330 Win=0 Len=0
120950 23:56:03.459708 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=3929990 Win=0 Len=0
123894 23:57:13.019794 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=4239218 Win=0 Len=0
124635 23:57:27.808398 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=4357394 Win=0 Len=0
128083 23:58:40.133278 78.129.220.51 10.0.64.200 TCP bmap > ewall [RST] Seq=4916930 Win=0 Len=0
 
I still have problems. Again.

My latency ranges between 145 and 210. My DL ranges between 480 and 520. UL is roughly 210 or so.

I get disconnects every 3/4 times. Explaining to a client the problems get's a "So is that my problem?"

Embarrasing.

I actually rue the day I joined Screamer now. This is ridiculous.
If only Screamer techs were as efficient and professional as wow4life.

He doesm't even work for Screamer, yet provides us with more feedback..
:mad:
 
Hi Guys

I am sorry I have not been active in the last day but we are very, very busy with something big which will be announced on Monday.
As part of these preparations we are changing some of our upstream routes and we have just realised that this has had a negative effect on some of our network which we will fix in the next 50 mins.

@iDentiTy

We had a major hit on our Helderkruin tower and the techies are working on it as we speak and should have it replaced by tomorrow morning.
 
Some of the problems are not related to this mysterious RST - sometimes it is a "valid" issue as I have experienced a couple of times over the last hour - where the server sends a RST after trying 3x to retransmit a packet.
 
howzit said:
Hi Guys

I am sorry I have not been active in the last day but we are very, very busy with something big which will be announced on Monday.
As part of these preparations we are changing some of our upstream routes and we have just realised that this has had a negative effect on some of our network which we will fix in the next 50 mins.
Click to expand...

Can you please provide us with some more information as I would like to understand what the issue was/is.
 
Interesting to see what plans are in store for on Monday, I know its is frustrating when you trying to use online applications like WoW or Ventrillo and get constantly disconnected every 30 minutes, its can cause problems.
 
Last edited:
diegoa said:
Hope to see what plans are installed for on Monday, I know its is frustrating when you trying to use online applications like WoW or Ventrillo and get constantly disconnected every 30 minutes, its can cause problems.
Click to expand...

Agreed - I have given up accessing work applications from home and drive into the office instead (even when it means going there late in the evening if I need to collaborate with colleagues in the US).
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X