Hello, linux users that cannot login.
I fixed the problem on my computer by running
echo 128 > /proc/sys/net/ipv4/ip_default_ttl
as root.
you can also run
sudo sysctl net.ipv4.ip_default_ttl=128
this fixed the problem for me on NixOS staging
1 Like
2018
whoopsie
This fixed the problem for me on Classic. But for retail something else seems messed up, I can log in and hear my character and wow sounds, but the game window shows a frozen login screen.
This worked for me last night. Had issues again today, ran it again and it worked instantly. Must have reset or something when I rebooted. Thanks again.
This worked for me. Ubuntu 18.04 and Wine Staging.
THANKS SO MUCH.
@Blizzard – you make me sad.
Howdy!
I wanted to make sure you all knew we are investigating these connection issues. I do not have any additional information to provide at this time. Just know we are on it.
Thank you.
3 Likes
Thank you @Zuvykree. This will be of great relief to many of us across multiple operating systems and WAN access devices. I know myself and many of the people involved in this effort have been hopping forum to forum to assist people with thier accounts. An official fix or at least position for it would be detrimental to a permanent solution, whether community supplied or developer supplied.
Thanks again to everyone who has assisted in these efforts!
1 Like
Upon further investigation, I know a guy who says this may be related to a “Mirai” botnet attack using linux based internet of things. The default TTL for many linux seems to be fairly high - as much as 255. So setting the ip_default_ttl to 128 matches your system with what Windows 10 typically has for a setting thereby making your machine be not targeted for packet dropping.
I understand that Blizzard’s core business is windows and mac users and linux users are a tiny fraction. It would be really nice to at least have some kind of ability to reach out to the linux users and give them a simple fix like what was posted above rather than have to rely on crowd sourcing. Changing the setting on gaming systems would not have an impact on all the IOT systems in the wild that are actually responsible for the bad packets.
This is a mititgation technique to deny access to bot nets for sure, it is a passive check that blocks on certain TTL values (this may not be the only thing they are checking packets via DPI on but at least the work around for most of us is rather easy)
I’ve posted several things about this issue, combined multiple fixes on each of the 3 forums I know about. and personally proven this is fingerprinting based on linux using NAT vs bridged networks on my linux box via vmware workstation [vm player])
This only started to happen just after ‘they continued to monitor the situation of the DDOS attacks’ and legit blocked several VPN / Android mobile or tether customers / windows 10 users of certain builds that use odd TTL values / etc, even the odd mac user is blocked.
Some could be IP bans, others could be user temp bans, or a combination of all of the above.
1 Like
^ What this fellow said.
Came back between Blizz DDoS tweets long enough to level an alt to 7 then dc’d. I waited it out until the launcher didn’t display the announcement and still I timeout on every realm.
Side note, I was put into a 2min queue for the login server at one point before the massive server crash 
we got hosed.
Regards ipv4 I have been behind nat the entire time. The only thing needed for me was the increase in ttl. Which I have since dropped back to the default of 64 and it is still working. In game at the moment with tcpdump running on eth0 watching packets with ttl 64 leaving and packets from the game with ttl 51 coming back.
Yes blizzard uses 55 as the TTL for some packets I’ve noticed, spent a fair amount of time examing and testing stuff before going to bed (actually found it more fun compared to playing wow… oddly enough)
Being behind NAT with the TTL adjusted will work just fine, my linux box with a virtualization hypervisor software running in linux setup with windows 10 had the same issue until I bridged the connection to my router (meaning the OS had a good TTL but my linux box did not and it is all because the VM hypervisor uses my linux network default TTL as it’s own)
If I had made adjustments to my TTL on the linux box and used NAT on the VM it would have been just fine, it was just a proof of concept.
Another way you can get around adjusting the whole TTL is to try this
1 Like
I used sudo sysctl net.ipv4.ip_default_ttl=128 to change my ttl.
Can understand the fun angle. Some days puzzles like this or small coding projects can keep a person nicely occupied compared to the normal ‘fun’ things.
Tried a traceroute to the server I was connected to and it gets10 hops before things stop responding. So with me seeing a ttl of 51 for the packets hitting this machine it would be be higher than 55 at the server I was playing on. This was one of the Sydney servers. I am 7 hops just to enter Sydney.
Not going to worry about ttl mangling though I had checked my masquerading rules to see if they were doing anything. Now I am back to 64 turns out I was bored enough to try going smaller. Currently playing with a ttl of 16.
I can confirm this does work, I did see the Untangle router update sometime during the attacks. I am guessing some update went out to the linux users. I did not try this because I have never needed to do this but it appears now I will have too.
1 Like
Before I applied this fix, I was still able to connect to Oceanic servers. Does this mean that those servers are still vulnerable, or that it was just a poor implementation? If it’s the former, Blizz may want to look at that before they get hit. If it’s the latter, maybe look into the difference between implementations…
Some of their IP ranges don’t seem to have this DDOS protection in it, I posted an iptables that changes TTL via mangle tables on the outbound for only 2 of their IP blocks, I found 1 IP block that did not seem to matter even though my game client for sure was speaking to it on their standard ports.
I’ve pretty much stopped looking into this issue since things seem to work with how I’ve implemented it, however if something changes I may look more into this but for now they need to figure this out for their customers instead of knocking them offline.
They are lucky we found work arounds… #passthebuck
1 Like
The Hero we deserve. TWITCH PRIME PEOPLE!
For those of you running Manjaro (Haven’t tested on other distros) here is a sure fire way to make sure the “ip_default_ttl” stays persistent when you reboot.
Open your terminal and paste this:
sudo -s echo "net.ipv4.ip_default_ttl=128" >> /etc/sysctl.d/sysctl.confIf you didn’t get an error, restart the computer. If you get an error: no such file or directory . Then you need to create this file. By using this commands you can create a file and write there an information about TTL.
sudo -stouch /etc/sysctl.d/net.conf echo "net.ipv4.ip_default_ttl=128" >> /etc/sysctl.d/net.confIf, for some reson it doesn’t stick after a reboot, go to /etc/sysctl.conf. Open it with SU and manually change it.
I have been thinking about this, and I do believe this issue is strictly related to Linux users.
As to why it also seems to affect windows/Mac users: routers usually rely on linux to perform their functions and provide web access to their configuration interface.
I bet if those with windows 10 connect “directly” to their internet provider’s modem, they would see their issue resolved. (As long as the ISP is a modem and not a modem/router combination.) Usually you can “bridge” the combination to just provide modem functions.