Hey Blizzard, I resubed a couple of days ago and since then I’m unable to play more than 10 minutes without being disconnected (Wow51900319 error) …
And before, you feed me the help speech, it’s worthy to note that I also play on the side, with some friends, good ole FFXIV ! And it runs flawlessly. In a 100 hours of playing, I never experienced a single disconnection nor even a bit of lag … And maybe we can’t compare games like that (different netcodes etc) but obviously, my ISP is working just fine !
On the other hand, browsing your forums, there are plenty of other cases of those random disconnections …
So, my question is this : When are you gonna drop the whole “it’s on client side” speech, acknowledge the issue and start working on a fix ?
Hi, Haeldir! o/
The problem with comparing your connection in different games is not the netcode. The problem is the path your connection follows to reach the server of said games.
For example, let’s assume you are in Paris and you want to go to Berlin by car. You find no issues whatsoever. It takes the expected time, and all goes flawlessly, great trip, 5/5, would drive there again.
Back in Paris, you decide to go to Madrid this time. And along the road you find some traffic jams and what not, making it longer than expected, nothing goes according to plan, and in the end, you have to turn back before even reaching the city because your vacation time is over.
Now, does it make sense to say that Madrid has an issue? No. It’s a road issue. Does it make sense to compare Berlin and Madrid based on the traffic experience on the trip to get there? Not much. Yes, your car was fine for both trips, but saying that Madrid needs to acknowledge this problem when it didn’t even happen close to them doesn’t make much sense.
We can try and help you figure out why the issue is happening, but we need some diagnosis files, preferably a winMTR. But first you need to understand that we are here to try and help you, not to lie to you. If there’s indeed an issue on our end, we want to have the information to be able to diagnose it too, and resolve it as soon as possible. We win nothing by having people unable to play.
Finally, someone who gets it. gives Agaleith a cookie - BTW, are you a new guy? Today is the first time I’ve seen that name.
Hey, Troviak! o/
Thanks for the cookie. I’ll enjoy it 
I’m indeed new in the forums, as you can probably guess by the fact that I have only 10 posts so far (11 now!). I hope to get along with everyone.
Hey,
so let’s give that traceroute a try …
WinMTR statistics
|Host |%|Snt|Rcv|Bst|Avg|Wst|Lst|
|FREEBOX |0|577|577|0 |0 |0 |0|
|crefac107-crefac-com |3|534|523|14 |15 |16 |15|
|amsterdam-9k-1-be1004-intf-routers-proxad-net |0|577|577|27 |28 |30 |28|
|80.249.208.83 |0|577|577|28 |32 |115|29|
|ae1-br01-eqam1-as57976-net |0|577|577|28 |31 |139|29|
|et-0-0-31-pe01-eqam1-as57976-net |0|577|577|28 |31 |125|29|
|137.221.66.43 |0|577|577|28 |28 |35 |29|
|185.60.112.157 |0|577|577|28 |28 |29 |28|
|Host|%|Sent|Recv|Best|Avrg|Wrst|Last|
|FREEBOX|0|730|730|0|0|0|0|
|194.149.164.48|3|670|655|14|14|16|15|
|amsterdam-9k-1-be1004-intf-routers-proxad-net|0|729|729|27|27|30|28|
|80.249.208.83|0|729|729|28|33|198|30|
|ae1-br02-eqam1-as57976-net|1|717|715|28|60|2419|29|
|et-0-0-67-pe01-eqam1-as57976-net|0|729|729|28|31|127|29|
|185.60.112.158|0|729|729|28|28|32|28|
|Host|%|Sent|Recv|Best|Avrg|Wrst|Last|
|FREEBOX|0|687|687|0|0|0|0|
|194.149.164.72|2|643|632|8|12|16|14|
|amsterdam-9k-1-be1004.intf.routers.proxad.net|1|667|662|22|26|41|28|
|80.249.208.83|2|647|637|23|30|118|28|
|ae1-br02-eqam1.as57976.net|2|647|637|32|37|125|37|
|et-0-0-3-br02-eqpa4.as57976.net|1|667|662|20|27|109|26|
|be2-pe01-eqpa4.as57976.net|2|647|637|32|35|39|38|
|185.60.114.159|2|647|637|32|35|40|38|
Hi, Haeldir, and thank you for this information! o/
So, a really quick explanation of what we are seeing here, so you can follow along: each line is a point or node along the path the data takes from your router to our servers. The first line is your router, the second one is a node close to you, the third one a node apparently in Amsterdam, and so for until you reach our servers in the last line.
The columns give us different data from said node. The most intereseing ones for us are % (percentage of packages sent that didn’t come back from that point), Avg (average time for packages to get there and back), and Wrst (longest or worst time for packages to get to the point and back).
With this in mind, you can see really quick that in the second line in the three tests there’s a consistent package loss (3-2%). While it may not seem too high, it can affect games like WoW or Overwatch, that are relatively sensible to these things. Notice how in the last test this spreads to every single line (which is normal. If you lose packages when reaching the first node, any node you try to reach passing by that first one will show similar results).
Now, where things get worrisome is when we start seeing between the average and the worst times, because that means that there are intermittent issues causing high latency that usually is not there, which is what you are experiencing in the game. We are always looking for the first line where this happens, as it will spread from there.
This happens in the first test in the 4th line, 80.249.208.83. You can see that the average is 32 milliseconds, which is pretty decent, but it has spikes of 115. Not terribly high, but it’s bad news.
We see the same result in the second test, again in the 4th line (same IP, so it’s the same node as before). Again, average of 33 milliseconds and spikes of 198. The next line though, ae1-br02-eqam1-as57976-net, goes up to 2419 milliseconds, or almost 2 seconds and a half. That’s a disconnection.
In the last test, the results are similar, although we see a slight spike in the Amsterdam line too, from 26 to 41. But it’s in the 4th, 80.249.208.83, where it goes up to 118, and spreads from there.
So, with this in mind, I think we can safely conclude that there’s some problem in the node with the address 80.249.208.83, which is a node in the Netherlands. There may be some issues with ae1-br02-eqam1-as57976-net, but that’s probably just spreading from the previous one.
Unfortunately, this means that neither Blizzard nor you can do anything directly about it (we can’t tell you to go and restart that node for example, like we could if the issue was your router). What you need to do in these cases is call your ISP. Explain to them the situation with this information at hand, so that they can check the node at 80.249.208.83, or notify it to the people responsible for said node. Hopefully, it can be resolved soon enough so that you and anyone else that connects to us through that node gets this resolved as soon as possible
Aaaand… this ended up being longer than expected, but hopefully this information is useful.
That doesn’t solve the issue because that is a node that is operated by blizzard as it has been delegated the IP block by that exchange in Amsterdam and said exchange says they take no responsibility for the operation of those nodes and responsibilities for it fall to the customer, in this case Blizzard
This is information that is available publicly on the IP blocks RIPE listing.
we’ve been trying to tell you that is the failing node for a while now.
I have a thread up myself on the forums for about 4 days now with a lot of diagnostic data for you on this specific issue too.
Edit: Should specify the issue is the block of IPs found in the IPs assigned to the hostnames under et-0-0-2. Not just that IP mentioned above. There are secondary issues including Bandwith Saturation, High Jitter, High Ping Spikes.
Another example would be the IP 137.221.65.18 where the issue is also observed.
These are all IPs leased by Blizzard from Amsterdam Internet Exchange B.V. some with pretty different IPs, which means the issue could be less specific to a single node and perhaps a more broader issue with infrastructure or implementation of handling of traffic in said infrastructure.
im getting the same error code at least 30 dcs a day other games run perfect
Hi, Verstab! o/
I’m not working in the forums at the moment (I’m on my lunch break, actually), but I saw your reply, and wanted to go over a few things really quickly (I’ll try to post in your thread in a few hours once I’m back with any insight I get).
First of all, it’s clear you know what you are talking about, so I’ll skip most things.
The IP 137.221.65.18 you mention in your post is indeed managed by Blizzard, but I don’t see it in any of the test in this or your thread. If you have any test showing that node having issues, I would appreciate if you posted it in your own thread, as I’ll go over it in depth later (I don’t have the IPs for the host names either, so if it corresponds to any of the host names, just let me know which one).
The IP 80.249.208.83 though appears to me as managed by Amsterdam Internet Exchange B.V., as you mention in your post yourself. I’m not aware of this being a node we manage in any way, but I’ll pass it on, just in case, as I don’t have access to all the information regarding our network infrastructure, and there could be something I’m missing, for sure.
While this may not be something we say too often, we are investigating this issue internally too, as we know many of you are affected and if there’s something we can do, we want to do it, even if it’s outside of what we manage directly. We’ve sent reports to ISPs and the like about players being unable to connect to us in the past, for example. It’s just that so far we’ve been unable to identify any issues on our end, but we gather as much information as we can whenever an issue like this arises and we send it to our teams to see if there’s anything that can be done from our end. So while we try to offer the most immediate solutions here, rest assured that we do review this information internally too.
Hey, thanks for the response.
Feel like I’ve been yelling into the twisting nether for a few days here lmao.
Like I said in my own thread, without knowledge of how Blizzard’s network works, there’s only so much I could gather, so thats why the et-0-0-2 IPs I was querying were hardly systematic and uniform in test cases, since it was luck of the draw on what I got out of there along my route on each test.
What I have noticed is consistantly there are issues on the et-0-0-2 IPs, if you have a range of the IP addresses for them I could go through and collecting a lot more data, but that’s something that would probably be better done on Blizzard’s side on the basis of internal testing being more efficient than poking and prodding around and of course, posting a list of those would make things infinitely easier for potential attackers to target key nodes on the common routes, but as afore mentioned I can only make observations based on whatever et-0-0-2 I get each time.
I did include pingplotter data for each test from both my home location and a server I have, alongside the WinMTR data and that will go into a lot more depth if downloaded or viewed in browser.
But either way, thanks for the response and can pick things back up over in my own thread if theres any new informtation.
Ok, so there is nothing that can be done … Bummer ! Guess it’s bummer too for the sub money Blizzard already pocketed heh …
Sooo just out of curiosity, I tried that WinMTR test on FFXIV euro datacenter IP. Here comes
WinMTR statistics
Host % Sent Recv Best Avrg Wrst Last
FREEBOX 0 519 519 0 0 0 0
194.149.164.74 7 408 380 14 14 16 15
194.149.166.50 0 519 519 14 14 15 14
No response from host 100 103 0 0 0 0 0
ae-1-3104-edge3-Paris1-Level3-net 0 519 519 14 14 40 14
global-crossing-xe-level3-paris1-level3-net 0 519 519 14 14 50 15
po6-ar4-LON3.gblx-net 0 519 519 21 22 209 21
eidos-vpn.gigabitethernet3-39.ar4.lon3.gblx-net 0 519 519 22 23 33 23
209.130.141.196 0 519 519 21 21 25 21
eu.square-enix-com 0 519 519 21 21 28 21
Funny thing, there’s a 7% loss at the second node and yet I got absolutely zero disconnection from FFXIV ! I’d be curious to read any explanation on that 
Hi again, Haeldir! o/
As I mentioned in the original reply, the worrisome part is not the package loss (although it’s something to pay attention to), but the spike in latency in the node 80.249.208.83, specially when we see spikes of over 2 seconds.
Package loss doesn’t always mean there’s an issue. It’s something you can almost ignore if you don’t see it spreading down, as it may be the result of the security of said node. In this test you can see that no other node has any package loss, which would be unusual if indeed a 7% of packages don’t reach the second node (you can’t reach the third without going through the second one after all).
In the third test you posted originally we could see that 2% spreading down, which is why I pointed it out, but again, where the main issue seems to be is at the node 80.249.208.83.
Regarding the subscription, I can’t comment on that since I don’t have access to the purchase information, but feel free to contact a Game Master through a ticket, and they can have a look at the different possibilities. I can’t promise anything, but we’ll do what we can.
FWIW, in another thread, one thing people found was that increasing your TTL helped. I’m playing from Linux, and got the 51900319 error all the time since the DDoS stuff happened. Upped my TTL to 128, things are much better now. I get an occasional streaming error disconnect, but that happens rare enough to be able to live with it.
(As an additional info, I also have a Mac Mini, had no issues playing from there, even though it’s on the same network, and traceroute is exactly the same from there and from my Linux PC.)
Hi, Tinkspring! o/
Thanks for your suggestion. This is indeed something that helped a lot of people, but usually those that couldn’t even reach the character selection screen.
After hearing about this solution though, our teams had a look into it and found that they could make it so that people affected by this could connect again without any needs to change the TTL, and we haven’t had any new reports in the last 3-4 days.
If you find this helps now, let us know, as we may have to take another look at that.
Dropped my TTL to the default, so far so good. We’ll see if the streaming errors persist.
Thanks!
I found my ducky keyboard had the keystroke rate suddenly increase and it spammed WOW and disconnected me. Try walking in wow using just your mouse 1 and 2 together, does it do the same?
My ducky keyboard i had to press FN+F5 i think to lower the keystroke rate and fix my issues in WOW
Hi again, Haeldir! o/
I was discussing your case with some colleagues, and one pointed out that you should be able to activate IPv6, but you are using IPv4 at the moment to connect to WoW.
This option is in the game. Press Escape, and go to System. In the Network section you’ll see the option to Enable IPv6 when available. You may need to restart the game after this. Let us know if this helps
erm. What host adress do i type to try this program. Or does anyone do?
Hi, Goodguylock! o/
If you mean the winMTR, in the bottom of the article you have a small menu to select the game, in this case it would be WoW. There you will see a list of the appropriate IP addresses 
I solved my issue like the true hacker I am. I used update in windows and Net framework was installed from Microsoft. That solved everything. If only i can remember to update my windows more often 