Screamer - TCP RST

I honestly cant belive why this issue has not been resolved for Screamers gamers.
 
Screamer offer static IPs however they still pass through NAT ... weirdly enough. I tried it and it certainly didn't solve my problems.
 
wow4life said:
Connection was really solid from about 9pm to 12pm after a couple of disconnects just prior to 9pm.

Will see how it goes tonight...
Click to expand...

Lots of random disruptions lately, about 1-2 minutes at a time. Every time the trace dies at 196.15.204.81
 
My current stats:
Ping statistics for 209.85.227.105:
Packets: Sent = 628, Received = 596, Lost = 32 (5% loss),
Approximate round trip times in milli-seconds:
Minimum = 242ms, Maximum = 424ms, Average = 341ms


Not good :/

Back to 3G this afternoon for me ....
 
Last edited:
Is there not maybe a way to block the rts packages? If there is this could be used as until screamer address the problem:confused:
 
Nope as an RTS occurs for a reason - it is a symptom not the problem itself.

Problems include timeouts between two parties, NAT issues etc

I think that the solution lies is the allocation of public/static IPs but I could be wrong ... although the symptoms and solution is very similar to a problem that online gamers were experiencing with Neotel. Those with static IPs are smiling now ... (assuming that didn't have other issues related to their wireless connection).
 
Yup, I experience something similar although haven't really tried investigating it.
Periodic disconnects anything between 3 minutes and an hour. Then some days I can stay connected for hours; although this is a very seldom occurrence.

Switched over to 3G for a while and had no problems.

Speaking of which I am currently using my 3G... last night there was no connection and today although I am able to connect there seems to be a problem further upstream.

HIGHLY annoying!!
 
Migrainuer said:
Yup, I experience something similar although haven't really tried investigating it.
Periodic disconnects anything between 3 minutes and an hour. Then some days I can stay connected for hours; although this is a very seldom occurrence.

Switched over to 3G for a while and had no problems.

Speaking of which I am currently using my 3G... last night there was no connection and today although I am able to connect there seems to be a problem further upstream.

HIGHLY annoying!!
Click to expand...

Do you have wireless association? If not it might be a similar problem to mine where my base station switched when Mnt Road went down.

Had to change the base station mask to force it make to Mnt Road.
 
Update:
* Installed a packet filter and removed all TCP RST packets received from server

Positive:
* No disconnects

Negative:
* Highlights the real (?) issue - when I filtered out the resets it was accompanied by high lag spike, which leads me to believe that the resets are there for the reason intended i.e. to revive dead/stale connections.

Conclusion:
* Too early to be sure but I think that packets are getting lost from the server -> client.
* The reason I don't normally see this is that I test lost packets from my client -> server and not the other way around. Although admittedly my packet loss from client -> server is higher that normal at approx 1% to 2%.
* What I am not clear on is why the packets are being lost. Is it a NAT issue or somewhere else in the infrastructure?


The filtered packets (and a lot of them):

No. Time Source Destination Protocol Info
37839 20:43:28.883506 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=136778 Win=0 Len=0
56917 20:56:32.285397 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=2369558 Win=0 Len=0
68032 21:02:59.021446 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=4486606 Win=0 Len=0
76431 21:08:09.323078 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=6250622 Win=0 Len=0
87582 21:16:25.765903 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=9769378 Win=0 Len=0
88757 21:17:06.248001 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=10154518 Win=0 Len=0
92525 21:18:58.379472 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=10980806 Win=0 Len=0
101216 21:23:44.788166 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=13199818 Win=0 Len=0
119828 21:35:07.002171 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=16443402 Win=0 Len=0
120177 21:35:20.466205 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=16485178 Win=0 Len=0
120792 21:35:45.889294 213.175.194.144 192.168.2.32 TCP ssh > 4920 [RST] Seq=16553838 Win=0 Len=0
 
Last edited:
Well, I have been monitoring it... and it's definitely the same issue.
Period resets... there does not appear to be any pattern.

It can be fine for hours and then reset a few times in the space of a few minutes...

What Packer Filter did you use?
 
Migrainuer said:
Well, I have been monitoring it... and it's definitely the same issue.
Period resets... there does not appear to be any pattern.

It can be fine for hours and then reset a few times in the space of a few minutes...

What Packer Filter did you use?
Click to expand...

I use the Windows version of ipfw, called wipfw. I disable my normal anti-virus firewall and use this instead (behind my router's firewall). Btw I have only tested in Windows XP.

I pieced together some tips (including information from SBHacker *ouch*) and it seems to be working - here goes:

Following these steps

(1) Download wipfw at: http://downloads.sourceforge.net/wipfw/

(2) Unzip to somewhere like c:\program files\wipfw

(3) Assuming you run behind a router with a firewall (else it is more complicated and you will have add a lot more ports manually) double click "install.cmd".

(4) Disable Windows Firewall or your anti-virus package firewall

(5) Save the following text in the file Windows\System32\drivers\etc\protocol. NOTE: This file was already there on my machine but I included for completeness.

QUOTE(protocol)
# Copyright © 1993-1999 Microsoft Corp.
#
# This file contains the Internet protocols as defined by RFC 1700
# (Assigned Numbers).
#
# Format:
#
# <protocol name> <assigned number> [aliases...] [#<comment>]

ip 0 IP # Internet protocol
icmp 1 ICMP # Internet control message protocol
ggp 3 GGP # Gateway-gateway protocol
tcp 6 TCP # Transmission control protocol
egp 8 EGP # Exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # User datagram protocol
hmp 20 HMP # Host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
rvd 66 RVD # MIT remote virtual disk

(6) Edit c:\program files\wipfw\wipfw.conf and replace the contents with the following (btw I deny tcp resets from Gamemax servers and the default wow port as I alternate between the two):

#################
# wipfw.conf
#################

# First flush the firewall rules
-f flush

# Deny TCP RSTs on Wow tcp port
add deny tcp from any to me 3724 tcpflags rst
# Deny TCP RSTs from Gamemax proxies
add deny tcp from pamela.gamemax.org to me tcpflags rst
add deny tcp from kimberly.gamemax.org to me tcpflags rst
add deny tcp from denise.gamemax.org to me tcpflags rst
add deny tcp from angelina.gamemax.org to me tcpflags rst

(7) Open a command prompt and run the following two commands:
(8.1) net stop ipfw
(8.2) net start ipfw

(8) Check it is all working with the following command:
ipfw show

NOTE:
* If you are not behind a router's firewall then this will open you up to all type's of attacks. There are configurations that you can specify to protect you but I haven't included it.
* Don't do this if you are not comfortable with what you are doing
 
Anyone else tried this?

Obviously it doesn't help where there are serious issues causing the disconnect (for example too many lost packets).
 
Why a work around when you pay for a service that suppose to be working? If it disconnects WoW and various applications continously there is ongoing problems.
 
I downloaded a trial version of NSAuditor which allows me to specify what I want to filter.
My WoW connection is certainly more stable although the latency has gone up by around 200ms.

What I found last night, running a ping test to google.com
Sent: 43572 Received: 41347 Lost: 2225 (5% loss)

That is just ridiculous!!!
 
Migrainuer said:
I downloaded a trial version of NSAuditor which allows me to specify what I want to filter.
My WoW connection is certainly more stable although the latency has gone up by around 200ms.

What I found last night, running a ping test to google.com
Sent: 43572 Received: 41347 Lost: 2225 (5% loss)

That is just ridiculous!!!
Click to expand...

I worked very late last night and didn't check my connection - but I am seeing very similar tonight.

I can complain all I want but the only options for me are iBurst and Neotel WiMax and based on feedback they don't seem to be any better.

I will move house early next year and I will have adsl as a requirement.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X