Cannot join any lobby

After a 90002 (I think) error approximately 2 hours ago, I have been unable to login to any datacenter with error 2002. Oddly I can ping the datacenter lobby just fine before clicking Start or picking from the Datacenter picker. The pings go dead immediately upon trying to connect.

Example screenshots of me attempting to connect to Aether here

Packet capture of an attempt to connect to Dynamis available if needed.

Tracert for the curious:

Tracing route to 204.2.29.6 over a maximum of 30 hops

1 2 ms 1 ms 1 ms 192.168.1.1
2 11 ms 9 ms 9 ms syn-072-031-146-053.inf.spectrum.com [72.31.146.53]
3 11 ms 10 ms 10 ms int-0-0-43-3.bkfdcaewzh1.netops.charter.com [71.46.169.23]
4 10 ms 9 ms 8 ms lag-22.bkfecandzp1.netops.charter.com [72.31.28.194]
5 9 ms 9 ms 8 ms lag-10.bkfecandzp0.netops.charter.com [72.31.28.190]
6 * 27 ms * lag-19-10.lsancarc0yw-bcr00.netops.charter.com [107.14.16.234]
7 20 ms 21 ms 20 ms lag-800.pr2.lax00.netops.charter.com [66.109.7.225]
8 19 ms 19 ms 34 ms ae3.cr7-lax2.ip4.gtt.net [208.116.213.117]
9 22 ms 22 ms 26 ms ae22.cr3-lax1.ip4.gtt.net [89.149.181.102]
10 22 ms 21 ms 23 ms ae-3.a04.lsanca07.us.bb.gin.ntt.net [129.250.9.105]
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 ^C

Edit 2: Fired up a VPN and was able to hit character select before getting 2002'd after selecting a character.

I'm having the exact same issue with the pings going dead as soon as I try to connect. For now I'm using a VPN to get in but it's less than ideal.

Still happening.

Edit: Although, I can connect to the Japanese and European datacenters with no VPN so I guess it's just an ISP routing issue out of their control.

Quote:

---

Originally Posted by Bikonito

Still happening.

Edit: Although, I can connect to the Japanese and European datacenters with no VPN so I guess it's just an ISP routing issue out of their control.

---

There was that one router bug that the Factorio devs found in the wild. When the packet checksum was 0x0000 the packet got dropped...

I'm investigating that now.

OK...

My TCP PDUs are varied checksums, but my outgoing IP packets are all 0x0000, likely because I have a setting wrong somewhere in my network stack (that I've now fixed, Windows was set to offload checksums to hardware but hardware wasn't doing them). However, both successful and failed connections show this, so that isn't it.

However, tugging on this thread lead me to another thing. The IP packets have the "do not fragment" flag set. So if there is an MTU misconfiguration anywhere in the world between you and the server, the packet never makes it. VPNs would get around this at least partly by hiding the IP packet in another packet that could be fragmented, hopefully bypassing the issue. But... the packets that fail are only ~700 bytes, so it would have to be a horrific misconfiguration for that to be the case. Of course, why it is even that large when the last 500 bytes of the data are all 0s is beyond me.

While I feel like the "do not fragment" flag is going to cause trouble for some users, it does not at all explain the refusal to respond to pings that happens after Biko Nito and I have problems.

@Bikonito If you want to give it a shot, try doing running a ping from the command prompt with the -f and -l flags, set the number after -l to something like 1000 and see if the ping fails. Back the number down until they start succeeding.

And, of course, after 2 days of smooth sailing, the issue is back for me. Interestingly the server goes unresponsive on a different part of the handshake this time.

I wonder if we're running afoul of some sort of DDOS protections. Like our ISPs (Spectrum for me) are flagged or there is a misconfigured rule somewhere.

Still happening today, despite an around the world trip via Nord VPN.

Still happening for me as well.

Had the other way round, with VPN error, turned off VPN all was well.