Linux users unable to log in, WOW51900328/329 error after logging in

It works!

Thanks guys!

I just went into the linusxshell and added the TTL fix to the sysctl.conf file.

meh, this is an easy unsub … #notuxnobux

Any solutions for Windows 10 users? I can’t get on…

Did you try changing your TTL to 128 ?

No, no idea how to do that. It’s 64 atm.

open up a administrator CMD prompt and type the following in:

netsh int ipv4 set glob defaultcurhoplimit=128

Editing file ip_default_ttl in directory /proc/sys/net/ipv4/ from 64 to 128 worked for me.

Ubuntu 18.04

Enable SSH on your webUI (likely 192.168.1.1) using the following directions
wiki.untangle.c**/index.php/Enable_SSH

Use an SSH client like PuTTY and:
ssh root@<routerIP>

Use the admin password you use on ther webUI
once in just run
echo 128 > /proc/sys/net/ipv4/ip_default_ttl

Don’t forget to disable SSH afterwards

I’m a Windows 10 user with an Untangle firewall, This fixed it for me.

1 Like

OS’ impacted so far:

Various distro’s of linux (large community of Ubuntu 18.04 LTS users)
Windows 10
Some MAC OS users

Linux users find ways to change their TTL from 64 to 128 in case the upstream provider is filtering by passive OS fingerprinting
to find malicious packets (packets with abnormal TTL so far has been one of the big trigger points)

Most linux distro’s right now and some windows 10 builds seem to be defaulting to 64 (less than that can be considered an old OS)
128 is the default for most Windows 10 builds

Work around(s)

  1. Change your OS TTL to 128 (or some value that works for you)

For Windows OS open up an administrator CMD prompt
type this into the big black command window: netsh int ipv4 set glob defaultcurhoplimit=129

For Linux distro’s use a search engine and figure out how to do it for your specific distro but what worlks for some is:
echo 128 > /proc/sys/net/ipv4/ip_default_ttl
or
sudo sysctl net.ipv4.ip_default_ttl=128
but to make it last on reboot you have to add this to your /etc/sysctl.conf file (where ever it lives/exists)
net.ipv4.ip_default_ttl=128

  1. VPN
  2. IPV6 when available (may require extra router setup)

Some end users report linux routers or NAT firewalls may require adjusting of the TTL in the case where TTL is changed by the router actively (or passively)

  1. Change your IP address (blacklisted) when passing through some ISP hand over connections (router to router)

In case of an IP address blacklisted
-Release your IP from the ISP (normally through your router)
-Change the mac address (on your router or device in front of your ISP device [sometimes these are combined all in 1])
-Make sure you save the change
-Renew the IP (on the device where you released it)

you may have to reboot a DSL/Cable or FTTH/FTTP modem to free the IP from the hardware provisioning server.

If none of the above work try a game scan/repair just to be safe.
Try classic instead of retail (faster, smaller, less BS caching)

DO try your account on another windows machine just to see if it will get in (maybe you have a black list on the account?)

Regards

Just thought I would add my voice here, after selecting my realm it did nothing till I got a error message. I first noticed it last night but was too tired to care and went to bed. Tonight I dug into it and found the TTL fix on the Lutris forums (currently waiting in a queue)

In case any debian/ubuntu/mint user come along and don’t find it in the previous posts (got to scroll slowly through a lot of posts), the fix is
sudo sysctl -w net.ipv4.ip_default_ttl=80

seen a few posts where people used 128 instead of 80

1 Like

The Windows users seem to have issues with their Linux-based firewall (e.g. Untangle) and not so much with their PCs

1 Like

Using Manjaro here.
sudo sysctl -w net.ipv4.ip_default_ttl=128 worked for me.

True, and the reason why I had suggested looking at their router or NAT device. (I’m expecting someone who uses Untangle to be able to figure that part out on their own) appreciate posting that close to my post.

Seems like this has been fixed by Blizzard. I just reverted my ttl back to the default of 64 and was able to login fine.

If this is true (I’ll be home within an hour to check it out) - awesome team work! Thank you all for contributing and posting the results.

Omg, where were you 20 hours ago!

j/k, but as of today after work, I was able to log in with no issues. My problem seems to have been resolved as well without any action on my end. Thank goodness, I’d really prefer not to go back to Windows and actually paying for software that breaks frequently and almost always in new and interesting ways…

(Manjaro, Grande Communcations, Wine-staging 4.15-1)

Nope still an issue.

But on a side note I can add an extra bit to 64 and make it 72 for the TTL and it works fine.

Huh. I just tried logging into a US server and indeed I still cannot connect. Oceanic servers seem to work, however. Maybe the fix(?) hasn’t rolled out to all regions yet.

As DDOS mitigation goes, TTL fingerprinting is pretty crude and unreliable. It’s sad that’s the best they think they can do, and it’s even more disappointing that they consider the Linux user community to be acceptable collateral damage.

However, they’re shot themselves in the foot with another group of users, this one fully and officially supported: users of the Mobile App. Android is based on a Linux kernel, so fingerprints the same as your systems. I “fixed” the mobile app on my rooted Nexus 6p by setting /proc/sys/net/ipv4/ip_default_ttl to 128 as well.

3 Likes