Looks like your connection to Bethesda.net Community Beta was lost, please wait while we try to reconnect.

​Datacenter N/A and a crude workaround



I have tested a little and this is what I have found so far:
It looks like Quake Champions tries too many connections on startup which will get interpreted as DOS by the network powers.
For example here is some output from Quake Champions on startup. We only care about ec2-52-57-114-63.eu-central-1.compute.amazonaws.com which seems to be one of the datacenters it tries to connect to.

$ tcpdump  -qln -i re0 udp and host ec2-52-57-114-63.eu-central-1.compute.amazonaws.com
Jun 14 11:33:10.013078 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6028, len 66)
Jun 14 11:33:10.013080 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6029, len 66)
Jun 14 11:33:10.013082 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6030, len 66)
Jun 14 11:33:10.013083 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6031, len 66)
Jun 14 11:33:10.013246 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6032, len 66)
Jun 14 11:33:22.263248 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6033, len 66)
Jun 14 11:33:22.263250 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6034, len 66)
Jun 14 11:33:22.263251 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6035, len 66)
Jun 14 11:33:22.263253 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6036, len 66)
Jun 14 11:33:22.263254 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6037, len 66)
Jun 14 11:33:23.995356 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6038, len 66)
Jun 14 11:33:23.995358 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6039, len 66)
Jun 14 11:33:23.995360 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6040, len 66)
Jun 14 11:33:23.995361 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6041, len 66)
Jun 14 11:33:23.995363 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6042, len 66)

As one can see, no answer ever makes it back.
However if we create a request by hand:
$ echo '1234567891234567891234567891234567899' | nc -v -u ec2-52-57-114-63.eu-central-1.compute.amazonaws.com 48801
We can see answers. 
Jun 14 11:33:38.598589 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 6328, len 29)
Jun 14 11:33:38.598590 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 11921, len 29)
Jun 14 11:33:38.598591 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 31283, len 29)
Jun 14 11:33:38.598592 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 29825, len 29)
Jun 14 11:33:38.599136 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 64, id 61058, len 66)
Jun 14 11:33:38.624030 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2610, len 29, bad ip cksum 0! -> cd54)
Jun 14 11:33:38.624949 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2611, len 29, bad ip cksum 0! -> cd53)
Jun 14 11:33:38.624954 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2612, len 29, bad ip cksum 0! -> cd52)
Jun 14 11:33:38.625145 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2613, len 29, bad ip cksum 0! -> cd51)
Jun 14 11:33:38.625151 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 38 (DF) (ttl 50, id 2614, len 66, bad ip cksum 0! -> cd2b)

 The same works when sending a hand crafted request from the same Windows machine that runs QC.
 (You can ignore the 'bad ip cksum' which is a false positive resulting from HW checksumming)
11:39:33.937606 192.168.10.43.55724 > 52.57.114.63.48801: [udp sum ok] udp 31 (ttl 128, id 6043, len 59)
11:39:33.963344 52.57.114.63.48801 > 192.168.10.43.55724: [udp sum ok] udp 31 (DF) (ttl 50, id 45547, len 59, bad ip cksum 0! -> 257b)
11:40:00.940303 192.168.10.43.55725 > 52.57.114.63.48801: [udp sum ok] udp 4 (ttl 128, id 6044, len 32)
11:40:00.968777 52.57.114.63.48801 > 192.168.10.43.55725: [udp sum ok] udp 4 (DF) (ttl 50, id 46299, len 32, bad ip cksum 0! -> 22a6)

I even wrote a little C program to send the exact packet that QC sends and get an answer back.

So we can asume that QC sends correct packets. My guess was that is just sending too much in a burst.
So I looked at the hosts to which QC tries to send data and blocked some of them that I am not interested in (non EU Amazon hosts since I am based in EU).
So I blocked udp requests to ports 4880[12] to these machines:
13.124.126.150, 13.54.84.40, 34.211.139.167, 34.211.229.229, 52.79.231.250, 54.207.86.124, 54.232.214.254, 54.254.218.37, 54.255.210.190, 54.66.132.147

Now at least I have Frankfurt back. I verified this by turning blocking on and off.
I may fine tune the host list some more later.

I can't play a full match atm. because @work, but it now found a TDM match in ca. 1 min. as it used to.



tldr; depending on your routing, it may happen that too many connection attempts at a time are made through the same route, you may get lucky if you block some of those on your home router/firewall. It seems to explain why a) only far away datacenters are visible (less connection attempts bundled + more diversification over time on a long route) and b) that it only happens to some.

Solution would be for QC to not send too many in one go, just spread them over 1 sec or more, better to need 1 - 2 sec. more at startup then the current situation.



is there "easy" way to do it? for noobs like me :)?



okay I just removed my router and connected my computer directly to the internet

It works now. 

How do I fix it now tho? I really need that router :/



ok, this solution works, just finished a pub TDM match without issues which I couldn't since the last patch.



@rednextomp said:

okay I just removed my router and connected my computer directly to the internet
It works now. 
How do I fix it now tho? I really need that router :/

 Your router should allow you to block some ip/ports. Most of them have some web interface.



Yes it has some, but I had bad luck finding something like "block something" etc

Why the game works fine without router tho? Is it blocking something by default?



I find if I click on the globe as soon as the game loads in the main menu, it'll go totally datacenter N/A and I have to restart the game

if I don't click on the globe everything seems to be okay...



@rednextomp said:

Yes it has some, but I had bad luck finding something like "block something" etc

Why the game works fine without router tho? Is it blocking something by default?

 Most likely. In some other thread someone mentioned that disabling syn-flooding did the trick for him. Time to consult your routers docs :>

Could also be literally anyone (ISP or other routers) in between us and the datacenter hosts of QC doing some weird blocking, the only proper solution is stopping sending so much traffic in bursts.



yeah I still can't figure how to block these addresses. My router is too old to have this function...



okay, another day without QC. I hope bethesda can fix it now, when LeopolD figured out what was the problem, because I cannot afford another router so I can play just 1 more game.



Great. This info should be VERY useful for devs, hope they fix these problems ASAP so we can play QC



Thanks a lot for this workaround. I got Frankfurt back too with this solution! :D



lets just wait and hope this post won't get lost 



@LeopolD_Bloom said:

I have tested a little and this is what I have found so far:
It looks like Quake Champions tries too many connections on startup which will get interpreted as DOS by the network powers.
For example here is some output from Quake Champions on startup. We only care about ec2-52-57-114-63.eu-central-1.compute.amazonaws.com which seems to be one of the datacenters it tries to connect to.
$ tcpdump  -qln -i re0 udp and host ec2-52-57-114-63.eu-central-1.compute.amazonaws.com
Jun 14 11:33:10.013078 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6028, len 66)
Jun 14 11:33:10.013080 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6029, len 66)
Jun 14 11:33:10.013082 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6030, len 66)
Jun 14 11:33:10.013083 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6031, len 66)
Jun 14 11:33:10.013246 192.168.10.43.58264 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6032, len 66)
Jun 14 11:33:22.263248 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6033, len 66)
Jun 14 11:33:22.263250 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6034, len 66)
Jun 14 11:33:22.263251 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6035, len 66)
Jun 14 11:33:22.263253 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6036, len 66)
Jun 14 11:33:22.263254 192.168.10.43.58841 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6037, len 66)
Jun 14 11:33:23.995356 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6038, len 66)
Jun 14 11:33:23.995358 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6039, len 66)
Jun 14 11:33:23.995360 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6040, len 66)
Jun 14 11:33:23.995361 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6041, len 66)
Jun 14 11:33:23.995363 192.168.10.43.58842 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 128, id 6042, len 66)
As one can see, no answer ever makes it back.
However if we create a request by hand:
$ echo '1234567891234567891234567891234567899' | nc -v -u ec2-52-57-114-63.eu-central-1.compute.amazonaws.com 48801
We can see answers. 
Jun 14 11:33:38.598589 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 6328, len 29)
Jun 14 11:33:38.598590 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 11921, len 29)
Jun 14 11:33:38.598591 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 31283, len 29)
Jun 14 11:33:38.598592 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 1 (ttl 64, id 29825, len 29)
Jun 14 11:33:38.599136 192.168.10.41.39891 > 52.57.114.63.48801: [udp sum ok] udp 38 (ttl 64, id 61058, len 66)
Jun 14 11:33:38.624030 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2610, len 29, bad ip cksum 0! -> cd54)
Jun 14 11:33:38.624949 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2611, len 29, bad ip cksum 0! -> cd53)
Jun 14 11:33:38.624954 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2612, len 29, bad ip cksum 0! -> cd52)
Jun 14 11:33:38.625145 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 1 (DF) (ttl 50, id 2613, len 29, bad ip cksum 0! -> cd51)
Jun 14 11:33:38.625151 52.57.114.63.48801 > 192.168.10.41.39891: [udp sum ok] udp 38 (DF) (ttl 50, id 2614, len 66, bad ip cksum 0! -> cd2b)
 The same works when sending a hand crafted request from the same Windows machine that runs QC.
 (You can ignore the 'bad ip cksum' which is a false positive resulting from HW checksumming)
11:39:33.937606 192.168.10.43.55724 > 52.57.114.63.48801: [udp sum ok] udp 31 (ttl 128, id 6043, len 59)
11:39:33.963344 52.57.114.63.48801 > 192.168.10.43.55724: [udp sum ok] udp 31 (DF) (ttl 50, id 45547, len 59, bad ip cksum 0! -> 257b)
11:40:00.940303 192.168.10.43.55725 > 52.57.114.63.48801: [udp sum ok] udp 4 (ttl 128, id 6044, len 32)
11:40:00.968777 52.57.114.63.48801 > 192.168.10.43.55725: [udp sum ok] udp 4 (DF) (ttl 50, id 46299, len 32, bad ip cksum 0! -> 22a6)
I even wrote a little C program to send the exact packet that QC sends and get an answer back.
So we can asume that QC sends correct packets. My guess was that is just sending too much in a burst.
So I looked at the hosts to which QC tries to send data and blocked some of them that I am not interested in (non EU Amazon hosts since I am based in EU).
So I blocked udp requests to ports 4880[12] to these machines:
13.124.126.150, 13.54.84.40, 34.211.139.167, 34.211.229.229, 52.79.231.250, 54.207.86.124, 54.232.214.254, 54.254.218.37, 54.255.210.190, 54.66.132.147
Now at least I have Frankfurt back. I verified this by turning blocking on and off.
I may fine tune the host list some more later.
I can't play a full match atm. because @work, but it now found a TDM match in ca. 1 min. as it used to.

 Do you happen to know the IP Addresses of the EU Data Centers?



Apparently my router does not have the option to block those IP adresses ;(



Nice post!
Could you please do a full list of the datacenters IPs?



13.124.126.150 - Korea
13.54.84.40 - Australia
34.211.139.167 - United States, Oregon, Portland
34.211.229.229 - United States, Oregon, Portland
52.79.231.250 - Korea
54.207.86.124 - Brazil, Sao Paulo
54.232.214.254 - Brazil, Sao Paulo
54.254.218.37 - Singapore
54.255.210.190 - Singapore
54.66.132.147 - Australia

52.173.131.28 - United States, Iowa
34.251.94.226 - Ireland, Dublin
52.49.163.0 - Ireland, Dublin
35.158.9.10 - Germany, Frankfurt
80.93.191.146 - Russia, St. Petersburg

These IP's can all be blocked if they're regions you don't wish to play in using the "Windows Firewall with Advanced Security" built into windows , right click 'Outbound Rules' and chose 'New rule...'. Chose 'Custom rule', then for Program Path  locate QuakeChampions.exe, leave it set to 'Any' protocol type,  all ports, then hit next and leave 'Any IP address' for the local address, then select 'These IP addresses' under the 'Remote Address' field and add the IP's one by one.

Edit:  Apparently some have found disabling flood protection on their own router has solve this issue for them, if you do that re-enable it once there is a fix patch out.



While experimenting at some point I blocked one or two ips too many. I could still find a match but was sent back to the infamous login screen after a while. So that issue that many experience may have the same root cause. 



@chax888 said:

I find if I click on the globe as soon as the game loads in the main menu, it'll go totally datacenter N/A and I have to restart the gameif I don't click on the globe everything seems to be okay...

clearly: it's orbs revenge if u make him angry !