Server Disconnecting Clients - Wireshark Proof - Server sending FIN TCP flag- BUG

[Packetdancer]

Everything up to the FIN looks fine: timely ACKs for received data from both sides and window sizes are in the green. I don’t see anything going wrong here. Of course we don’t know anything about the actual data being exchanged and whether it conforms to whatever application layer protocol FF XIV uses. The only thing different (compared to your other screenshots) is that this screenshot only shows data from one TCP connection — due to your filter (tcp.port eq 58899 and tcp.port eq 55026) — whereas your other screenshots showed that there are actually two TCP connections involved, both to port 55026 on the server. I have no idea why a FF XIV client needs/has two TCP connections to the same port on the server.

I haven't bothered to poke into the FFXIV networking protocol, so take this with a grain of salt, but... some games go for having multiple simpler networking protocols, like one for the state of a given session within an instance, another for the overall session. It wouldn't surprise me if FFXIV had something like that; one for your overall 'my character is logged in', and one for the connection to a given instance.

In a situation like that, the session service could tell the client something like "Okay, now you're zoning into Weeping City of Mhach, your instance connection should be to <raid instance server>" and it makes a second connection there. And when you leave the instance and it wants to put you back somewhere, the session server goes, "Okay, your instance connection should now be to <physical server that's running Limsa Lominsa for Spriggan>." It can be much simpler to maintain the one lasting session connection and then connect separately to each server that's running wherever/whatever you are, rather than having the server you talk to have to talk to the others behind the scenes, or having you forced to disconnect from the main server entirely to reconnect to other ones.

So two connections makes a lot of sense to me; it's how we were handling things with a game engine I helped write (before I burned out on game dev crunch time and bailed to less insane software development), back when we were modifying a fork of it to be used for an MMO. As the first game we were going to be doing atop the MMO variant of that engine got cancelled and I left before the second game atop it released, I don't know if that's the networking model they stuck with. But it was what we designed to start with while I was still in the room, and it wouldn't surprise me if FFXIV did something similar.

Honestly, it would also explain separate IPs for DoomAngel's account and DA's wife; the architecture we'd been discussing was that you had a 'world' server (in FFXIV terminology, this might be Spriggan), then several session/user servers (responsible for storing the data of specific individual users and managing their sessions) which the world server would point you at during login, and then the individual instance servers you'd be pointed to. If FFXIV uses a similar design, it might just be that the two characters are on different user/session servers.

My gut feeling—and this is spitballing, at this point—is that if we're only seeing one connection, and we're seeing packets go out and not get acknowledged, if something along the way is dropping outgoing packets (or mangling them in some way such that the FFXIV servers consider them invalid packets and drop them) when they're being sent to that specific IP address that seems to be authoritative for DA's account... well, I do know that if FFXIV doesn't receive valid heartbeat messages when it expects them, it will shut down the connection.

I'd still recommend trying the VPN approach, and the make-a-new-temporary-character approach. Making a new character might demonstrate the issue is IP-specific if that character ends up on a different user/session server within the same world and doesn't have the problem, or if the character ends up on the same one and does display the same problem. The VPN approach could show the issue is something along the route between DA and SquareEnix's data center (if approaching the server from a different network resolves the issue).

In some ways, I hope the VPN doesn't resolve it, because if it does it means the issue is in router configuration somewhere along the route between DA and the FFXIV servers, which would be a royal pain to track down (and presumably fall outside of SquareEnix's control). Which wouldn't be ideal, because I do imagine DA is not the only one affected by this, and if it's outside of SquareEnix's control there's not a lot they can do to resolve it for others. And even if the VPN works to solve things for DoomAngel right now, there'd be others who were affected by it who aren't posting here and wouldn't see such a solution get offered.

If the issue can be shown to exist regardless of how DA comes at the server IP (i.e. still exists over VPN), it means it's probably in SquareEnix's part of things; while that's less convenient for DoomAngel in the short run (because it means using a VPN isn't a workaround), it's probably better in the long run since then SE would have the ability to track it down in their stuff and presumably fix it for everyone affected.

Edit: unrelated, thank you for the mention of Convertio. I actually have been trying to find a web-accessible OCR service for a project that will need to do OCR as a stage of an automated pipeline, and poking at the Convertio site you linked to, their API suits my need 100%. So this thread has saved me a chunk of research I was about to need to do today on something wholly unrelated to FFXIV.