Error 2002: Investigation using Wireshark

This document is an attempt to clear up common misconceptions about the current situation with FFXIV login queues, specifically Error 2002 that can pop up randomly while sitting in the queue, forcing you to restart the client and possibly lose your spot. This is a pretty amateur analysis using Wireshark, but I am a professional networking/gameplay programmer with some TCP/winsock experience, so I do have a fairly good idea of what I’m talking about.

Contrary to the claims made by Square-Enix, Error 2002 is not an issue with your internet connection. If you have a terrible wifi connection and somebody in your house is using the microwave while you’re waiting in queue, the issue will obviously be worse, but even under PERFECT network conditions in your home, you can still expect to REGULARLY encounter error 2002 during peak hours. I have fiber internet and a direct ethernet connection to my computer, and I get it all the damn time despite having zero issues maintaining a connection to any other game or service.

In this document, I will show that mid-queue Error 2002 is a combination of several questionable decisions made in the networking implementation of the FFXIV client and server, which are collapsing under the weight of unprecedented load.

If all you want is the tl;dr, here you go: The game client is voluntarily closing a healthy connection every 15 minutes, forcing you to (invisibly) re-connect to the server as though you had just pressed the ‘Start’ button. When this happens, if the login server arbitrarily decides not to let you in, you will see Error 2002 and have to close the client. Even if you have perfect network conditions in your home you will still get Error 2002 randomly and there’s nothing you can do to prevent it.

Wireshark Analysis

Wireshark is a network logging/trace tool that allows you to capture all the information being sent back and forth between your machine and a remote server. In this case, the FFXIV Login Server’s IP address is 204.2.229.9, and my local IP is censored.

Here’s what a standard 30-second period of me sitting in the queue looks like. You can see that, for the most part, my computer and the login server take turns sending very small (50-100 bytes in the ‘Length’ column) packets back and forth over a perfectly healthy TCP connection. These packets are exchanged in bursts about every 5-10 seconds. (See ‘Time’ column.)

Roughly every 30 seconds, a much larger packet (highlighted in red) is received from the server. This packet, which is always 662 bytes in size, MAY contain an updated number for your new ‘position in queue’, or it may not. Your current position will never be updated outside of these packets every 30 seconds.

Here’s the interesting part. Every 15 minutes, your client will VOLUNTARILY drop its own connection to the loginserver and try to immediately reconnect. This process has nothing to do with the health of your connection or any kind of packet loss or lag - it happens every 15 minutes no matter what. Furthermore, this new connection is handled exactly the same as a fresh one - in the background the client is basically just pressing ‘Start’ again for you.

Here’s what you’re looking at:

Our local machine sends a FIN packet to the server, which is acknowledged via a response packet. FIN packets indicate that you want to gracefully terminate a connection. Note the timestamps and the IP addresses: My LOCAL computer is the one who drops the connection first.
Our machine then immediately opens a new connection with a SYN packet coming from a different local port but going to the same destination port.
The server acknowledges the new connection and begins sending us a sequence of (comparatively) large packets (highlighted in red). These likely contain authentication details and/or information about the queue.
The connection then continues like normal for another 15 minutes.

Now, here’s an example of an Error 2002 happening 15 minutes later:

We have a similar pattern:

Our local machine sends a FIN packet to close the connection, then a SYN packet to open a new one, exactly as before. The server acknowledges both of these packets.
We are not having any form of packet loss or communication issues. Everything we send is acknowledged and we are actively communicating with the login server.
Then, instead of sending the larger ‘welcome to the queue’ packets, the server immediately kicks us off with a FIN packet of its own, which we acknowledge. This happens LESS THAN A SECOND after accepting our refreshed connection.
After the server has sent this FIN packet, there is ZERO CHANCE of a graceful recovery. Your client makes no further attempts to communicate and the server isn’t going to send you jack shit because the connection is closed. Despite this, the client won’t even display error 2002 for up to 10 seconds, even though there’s absolutely no way for it to recover.

What does this mean?

We know that the FFXIV client voluntarily terminates its own connection with the login server every 15 minutes. After doing so, it initiates a new connection in exactly the same manner as though you had just pressed “Start” on the login screen. There is no functional difference between Error 2002 before entering the queue and the ‘random’ (every 15 minutes) Error 2002 that happens mid-queue. Both are examples of the Login Server rejecting a new connection due to some internal logic. It has nothing to do with network conditions in your home or anywhere else - all packets being sent are acknowledged properly. The server is just kicking you off.

Why is kicking you off? Who knows! Servers terminate connections for all kinds of reasons. It could be a bug. It could be intentional to prevent the server from crashing under load. It could simply be that the server is chugging so badly from all the connection attempts that an internal timeout is triggering. (Very unlikely, since it happens so fast after accepting the initial connection.) The point is that whatever the reason, the server is intentionally dropping your new connection, which means it’s something Squeenix can control. It has nothing to do with network conditions.

Here’s the really frustrating part: There is absolutely no reason why the client couldn’t just try again when this happens. Instead of having even the most BASIC sort of automatic recovery for your login server connection, the server gives the client EXACTLY one chance every 15 minutes to rejoin the queue, and if the server arbitrarily decides that it’s your turn to get kicked off, the client just gives up and forces you to log in again.

In my opinion, this is a pointlessly convoluted and frustrating way to engineer a login queue. It’s absolute nonsense that no attempt is made to gracefully reconnect when the server sends a rejection, and Squeenix is simply offloading all the busywork onto their players instead of fixing this incredibly fickle and sloppy networking code. The easiest fix would just be to have the client not terminate a perfectly healthy connection every 15 minutes. There’s no reason to do it in the first place!

The worst part is that the game wants you to THINK that it’s attempting to gracefully reconnect - you know when you’re logging in and you get this window?

Sometimes, you get to the character screen immediately, and sometimes it takes ~20 seconds before you get kicked off with Error 2002.

The game knows almost immediately if a given login attempt will be successful or not because the server responds immediately, every single time. When the server actively rejects you, the game just sits there doing nothing, making no attempt to reconnect, before displaying Error 2002 10-15 seconds later. Since you have a scant few seconds to get back in the queue before losing your place, the fact that the client actively wastes your time like this is totally unacceptable.

In other words, if you click Start and you don’t get to the character list within a few seconds, you might as well just close the client and try again. It’s just pretending to keep trying.

Square-Enix has had years to implement a modern queue system, but they have chosen not to invest the engineering time to fix the situation. Now, instead of owning up to the fact that their infrastructure is a baffling mess, they’re trying to tell people that it’s a problem with their internet connection. Utter nonsense. I love the game and the development team, but lying to their customers like this is simply unacceptable.

They don’t even need to build out more capacity or do anything expensive to result in a dramatically better user experience. Just patch the freaking client so it isn’t actively sabotaging itself.