Regular 90002 Errors

[PromethSikyon]

I can confirm this is a problem with the data centers where FFXIV is hosted just outside of Frankfurt, Germany. We get a lot of packet losses to the Chaos 195.82.50.9:

C:\Users\xxxx>ping -n 100 195.82.50.9

Pinging 195.82.50.9 with 32 bytes of data:
Reply from 195.82.50.9: bytes=32 time=42ms TTL=55
Reply from 195.82.50.9: bytes=32 time=49ms TTL=55
Reply from 195.82.50.9: bytes=32 time=50ms TTL=55
Reply from 195.82.50.9: bytes=32 time=45ms TTL=55
Reply from 195.82.50.9: bytes=32 time=48ms TTL=55
Request timed out.
Reply from 195.82.50.9: bytes=32 time=48ms TTL=55
Reply from 195.82.50.9: bytes=32 time=46ms TTL=55

We are on Deutsche Telekom 175Mbit connection. Pinging google servers for example, are not subject to packet losses. We are using Deutsche Telekom's normal DNS servers. Changing to 1.1.1.1 or google's 8.8.8.8 doesn't affect the loss of packet against Chaos 195.82.50.9.

[PromethSikyon]

CHAOS:

C:\Users\xxxxx>pathping -n 100 195.82.50.9

Tracing route to 195.82.50.9 over a maximum of 30 hops

0 192.168.2.201
1 192.168.2.1
2 62.155.241.3
3 217.239.60.1
4 * 80.157.129.202
5 4.69.163.30
6 195.16.161.162
7 80.95.144.23
8 195.82.60.45
9 195.82.60.29
10 195.82.61.14
11 195.82.50.234
12 195.82.50.9

Computing statistics for 300 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 192.168.2.201
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.2.1
0/ 100 = 0% |
2 --- 100/ 100 =100% 100/ 100 =100% 62.155.241.3
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% 217.239.60.1
0/ 100 = 0% |
4 --- 100/ 100 =100% 100/ 100 =100% 80.157.129.202
0/ 100 = 0% |
5 13ms 0/ 100 = 0% 0/ 100 = 0% 4.69.163.30
0/ 100 = 0% |
6 15ms 0/ 100 = 0% 0/ 100 = 0% 195.16.161.162
0/ 100 = 0% |
7 14ms 0/ 100 = 0% 0/ 100 = 0% 80.95.144.23
0/ 100 = 0% |
8 49ms 2/ 100 = 2% 2/ 100 = 2% 195.82.60.45
0/ 100 = 0% |
9 49ms 0/ 100 = 0% 0/ 100 = 0% 195.82.60.29
0/ 100 = 0% |
10 43ms 0/ 100 = 0% 0/ 100 = 0% 195.82.61.14
3/ 100 = 3% |
11 49ms 11/ 100 = 11% 8/ 100 = 8% 195.82.50.234
0/ 100 = 0% |
12 48ms 3/ 100 = 3% 0/ 100 = 0% 195.82.50.9

Trace complete.

LICH:

C:\Users\xxxx>pathping -n 100 195.82.50.52

Tracing route to 195.82.50.52 over a maximum of 30 hops

0 192.168.2.201
1 192.168.2.1
2 62.155.241.3
3 62.154.43.126
4 * 80.157.129.202
5 4.69.163.30
6 195.16.161.162
7 80.95.144.23
8 195.82.60.45
9 195.82.60.29
10 195.82.61.14
11 195.82.50.234
12 * 195.82.50.52

Computing statistics for 300 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 192.168.2.201
0/ 100 = 0% |
1 1ms 0/ 100 = 0% 0/ 100 = 0% 192.168.2.1
0/ 100 = 0% |
2 --- 100/ 100 =100% 100/ 100 =100% 62.155.241.3
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% 62.154.43.126
0/ 100 = 0% |
4 --- 100/ 100 =100% 100/ 100 =100% 80.157.129.202
0/ 100 = 0% |
5 13ms 0/ 100 = 0% 0/ 100 = 0% 4.69.163.30
0/ 100 = 0% |
6 15ms 0/ 100 = 0% 0/ 100 = 0% 195.16.161.162
0/ 100 = 0% |
7 13ms 0/ 100 = 0% 0/ 100 = 0% 80.95.144.23
0/ 100 = 0% |
8 49ms 6/ 100 = 6% 6/ 100 = 6% 195.82.60.45
0/ 100 = 0% |
9 50ms 1/ 100 = 1% 1/ 100 = 1% 195.82.60.29
0/ 100 = 0% |
10 46ms 0/ 100 = 0% 0/ 100 = 0% 195.82.61.14
15/ 100 = 15% |
11 50ms 22/ 100 = 22% 7/ 100 = 7% 195.82.50.234
0/ 100 = 0% |
12 54ms 15/ 100 = 15% 0/ 100 = 0% 195.82.50.52

Trace complete.

In both cases, servers: 195.82.60.45 and 195.82.50.234 are causing problems. And for LICH, 195.82.60.29 as well

As observed, the packet losses are happening within the data center itself.

Using VPN NordVPN or WTFAST doesn't solve the problem of packet loss.