connection errors

[YakuzaKiryu]

Adding myself here as I have had this issue since 6AM EST yesterday- as of 8:58AM EST I still cannot log in I get either 90002, 2002, or 10105 errors.

I have done dnsflush, replace and renewed my IP and I still cannot log onto NA, OCE. EU and JP are fine however. I have tried everything and I couldn’t raid yesterday so we cancelled.

I wish SE would fix this man.

[Vicious915]

I’m also having this issue since early yesterday morning when congestion is normally low. I too can connect to JP and EU data centers no problem. It’s connecting to the NA servers that is the issue; today I’m no longer able to connect to the Oceania servers whereas yesterday I was able to. Eventually I can connect to the NA data center and play the game which runs fine despite it telling me my connection is “Poor”. Once I log out it’s back to countless 2002 errors and on the rare occasion the 10105 error. The support rep who responded to my reply was most unhelpful and provided a link and told me to post here. So here I am posting hoping to give this issue more traction so it can fixed ASAP. I’m on PS5 so I unfortunately have no diagnostics to report. And I’m also in the Northeast and an Optimum customer.

[strigiformes]

I am also receiving repeated 90002, 2002, and 10105 errors when attempting to log in to Primal, Aether, and Crystal datacenters. I've been receiving these errors since around 8pm EDT last night (6/14) and just tried again this morning to test (10am EDT 6/15), receiving a 2002 error immediately. I'm on NA east coast.

I've tried dnsflush/winsock reset, which seemed like it did the trick once last night but has not been a consistent way to fix the problem (as soon as I attempted to move a character between DCs I was booted/errored out again).

As others have noted in this thread, it seems to be a gamble as to whether I'm able to make it past both the DC connection screen and then the character select without erroring out. After 20 minutes of repeatedly closing/opening the game last night, either due to lobby errors or otherwise, I was able to make it in for about an hour.

Using a VPN has helped, but only if I select a node on the west coast. This is not an option available to everyone, however, and I would like some kind of confirmation from SE that this issue is being addressed internally.

[DDRDiesel]

Reporting back to say this issue still persists as of 9:00 AM EST. Running the commands I mentioned previously seems to help, but it's still a roll of the dice from what I can see. Using the information below, I'll post the ping and tracert results

As per Square's page for reporting lag issues:
IP addresses for each of the physical data centers are as follows:
Japan: 124.150.157.15 (traceroute 124.150.157.15)
North America: 204.2.29.122 (traceroute 204.2.29.122)
Europe: 80.239.145.101 (traceroute 80.239.145.101)
Oceania: 153.254.80.65 (traceroute 153.254.80.65)
-----------------------
-----------------------
JP ping:
Pinging 124.150.157.15 with 32 bytes of data:
Reply from 124.150.157.15: bytes=32 time=185ms TTL=43
Reply from 124.150.157.15: bytes=32 time=179ms TTL=43
Reply from 124.150.157.15: bytes=32 time=179ms TTL=43
Reply from 124.150.157.15: bytes=32 time=178ms TTL=43

Ping statistics for 124.150.157.15:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 178ms, Maximum = 185ms, Average = 180ms
-----------------------
JP tracert:
Tracing route to 124.150.157.15 over a maximum of 20 hops

4 7 ms 4 ms 4 ms 451be0fc.cst.lightpath.net [65.19.99.252]
5 4 ms 3 ms 4 ms rtr3-tg10-1.wan.whplny.cv.net [64.15.0.42]
6 6 ms 4 ms 3 ms nyk-b7-link.ip.twelve99.net [62.115.153.104]
7 4 ms 4 ms 5 ms nyk-bb2-link.ip.twelve99.net [62.115.143.12]
8 76 ms 76 ms 75 ms sjo-b23-link.ip.twelve99.net [62.115.119.229]
9 182 ms 182 ms 181 ms tky-b2-link.ip.twelve99.net [62.115.123.141]
10 179 ms 180 ms 179 ms squareenix-ic-371309.ip.twelve99-cust.net [62.115.38.91]
11 178 ms 178 ms 181 ms 219.117.144.118
12 180 ms 179 ms 180 ms 219.117.144.45
13 177 ms 180 ms 177 ms 219.117.144.29
14 180 ms * 180 ms 219.117.147.182
15 178 ms 179 ms 180 ms 124.150.157.15

Trace complete.
-----------------------
NA ping:
Pinging 204.2.29.122 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 204.2.29.122:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
-----------------------
NA tracert:
Tracing route to 204.2.29.122 over a maximum of 20 hops

4 4 ms 4 ms 4 ms 65.19.100.4
5 3 ms 3 ms 3 ms 64.15.5.80
6 4 ms 3 ms 3 ms nyk-b7-link.ip.twelve99.net [62.115.153.104]
7 8 ms 6 ms 5 ms nyk-bb1-link.ip.twelve99.net [62.115.143.10]
8 4 ms 4 ms 5 ms nyk-b1-link.ip.twelve99.net [62.115.135.131]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.

Trace complete.
-----------------------
EU ping:
Pinging 80.239.145.101 with 32 bytes of data:
Reply from 80.239.145.101: bytes=32 time=93ms TTL=50
Reply from 80.239.145.101: bytes=32 time=89ms TTL=50
Reply from 80.239.145.101: bytes=32 time=89ms TTL=50
Reply from 80.239.145.101: bytes=32 time=91ms TTL=50

Ping statistics for 80.239.145.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 89ms, Maximum = 93ms, Average = 90ms
-----------------------
EU tracert:
Tracing route to 80.239.145.101 over a maximum of 20 hops

4 6 ms 4 ms 4 ms 64.15.4.58
5 6 ms 4 ms 12 ms 64.15.0.80
6 7 ms 3 ms 4 ms nyk-b7-link.ip.twelve99.net [62.115.153.104]
7 7 ms 4 ms 8 ms nyk-bb1-link.ip.twelve99.net [62.115.143.10]
8 * * * Request timed out.
9 86 ms 85 ms 84 ms prs-bb2-link.ip.twelve99.net [62.115.133.239]
10 92 ms 97 ms * ffm-bb2-link.ip.twelve99.net [62.115.122.139]
11 91 ms 93 ms 90 ms ffm-b11-link.ip.twelve99.net [62.115.124.119]
12 90 ms 88 ms 90 ms squareenix-ic-369631.ip.twelve99-cust.net [80.239.195.85]
13 90 ms * * 80.239.145.241
14 90 ms 90 ms 90 ms 80.239.145.101

Trace complete.
-----------------------
OCE ping:
Pinging 153.254.80.65 with 32 bytes of data:
Reply from 153.254.80.65: bytes=32 time=213ms TTL=236
Reply from 153.254.80.65: bytes=32 time=213ms TTL=236
Reply from 153.254.80.65: bytes=32 time=214ms TTL=236
Reply from 153.254.80.65: bytes=32 time=216ms TTL=236

Ping statistics for 153.254.80.65:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 213ms, Maximum = 216ms, Average = 214ms
-----------------------
OCE tracert:
Tracing route to 153.254.80.65 over a maximum of 20 hops

4 6 ms 4 ms 6 ms 64.15.4.56
5 6 ms 3 ms 3 ms 451be0ce.cst.lightpath.net [65.19.120.206]
6 5 ms 4 ms 3 ms nyk-b7-link.ip.twelve99.net [62.115.153.104]
7 6 ms 4 ms 5 ms nyk-bb1-link.ip.twelve99.net [62.115.143.10]
8 7 ms 4 ms 4 ms nyk-b1-link.ip.twelve99.net [62.115.135.131]
9 20 ms 7 ms 4 ms ae-17.a02.nycmny17.us.bb.gin.ntt.net [129.250.8.229]
10 8 ms 4 ms 5 ms ae-16.r21.nwrknj03.us.bb.gin.ntt.net [129.250.3.16]
11 23 ms 24 ms 16 ms ae-3.r25.asbnva02.us.bb.gin.ntt.net [129.250.6.116]
12 72 ms 78 ms 71 ms ae-2.r25.lsanca07.us.bb.gin.ntt.net [129.250.3.189]
13 74 ms 71 ms 72 ms ae-1.r24.lsanca07.us.bb.gin.ntt.net [129.250.3.218]
14 217 ms 214 ms 214 ms ae-5.r20.sydnau05.au.bb.gin.ntt.net [129.250.2.53]
15 216 ms 215 ms 215 ms ae-3.a00.sydnau06.au.bb.gin.ntt.net [129.250.4.28]
16 213 ms 216 ms 215 ms 199.245.24.25
17 215 ms 212 ms 213 ms 153.254.80.65

Trace complete.
-----------------------

I don't really know what else can be added to the thread with regards to significance. This isn't an ISP issue, nor is it a simple "Fix your internet at home" problem. The copy/paste responses from SE are getting stale. This is very obviously an issue with the routing from East Coast to the physical datacenter location, specifically right after the 8th hop listed above (nyk-b1-link.ip.twelve99.net [62.115.135.131]). That node itself most likely isn't the problem, it's whatever node is supposed to follow that hop that's either down, faulty, or otherwise problematic. Although this may not be an issue that Square can personally resolve, they most certainly have a responsibility to reach out to their NA providers to at least see if an investigation can take place at the node and fix the problem