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

[Packetdancer]

If something along the way would drop or mangle TCP packets, the server would simply not receive those packets or ignore packets with an invalid checksum. That didn’t happen AFAICS, because the screenshot shows no retransmits and ACKs of the server for all data sent by the client (except for the last two chunks already mentioned).

Ah, I should clarify; when I mentioned 'invalid packets' being dropped there I meant if anything happened such that the reassembled packets at the higher layer protocol (i.e., the FFXIV protocol, not down at the TCP level) could not be parsed properly after being received by the server, that's the sort of scenario that would usually cause the packets to be dropped by the server code. I could probably have been clearer on it. (But you're obviously right that we can't get a full picture of what's going on without knowing what's being seen on the server side.)

Knowing that a character seemingly tied to another IP doesn't seem to be suffering the same disconnects, I'd still be curious to know if a VPN affects the reliability of the first account. But either way, DoomAngel, I'm really glad that there's at least forward motion of you in some form.

[DoomAngel]

So far, VPN is proving to be working. I just played for an hour or so yesterday on it, and no disconnects yet. Will update when I get a bit more time to play on it, since it's still early to tell.

[Packetdancer]

So far, VPN is proving to be working. I just played for an hour or so yesterday on it, and no disconnects yet. Will update when I get a bit more time to play on it, since it's still early to tell.

Checking back in, since it's been a couple of days. Any update on whether the VPN worked long term?

[DoomAngel]

No disconnects yet while on VPN, so that's a positive. How do we troubleshoot further what the root cause of the issue is? I'd rather not be forced to use a VPN to play a game I already pay for. Any ideas?

[Moronica]

No disconnects yet while on VPN, so that's a positive.

Glad to hear that you’re finally able to actually play a game you’re paying for every month.
But in b4 SE telling you “See? The VPN fixed your internet!” and thus considering this issue fixed.

How do we troubleshoot further what the root cause of the issue is? I'd rather not be forced to use a VPN to play a game I already pay for. Any ideas?

I’m fresh out of ideas. You could check whether you’re connected to a different server through the VPN. If it’s a different server, that might indicate a problem with 204.2.229.93 itself. If it’s the same server, in b4 SE telling you “See? The VPN fixed your internet!”.

How many Square Enix employees does it take to change a lightbulb?

How many Square Enix customers reporting connection problems with Final Fantasy XIV and no other online game does it take for SE to actually investigate the problem?

So… how many Square Enix employees does it take to check a server’s log???

[Packetdancer]

Glad to hear that you’re finally able to actually play a game you’re paying for every month.
But in b4 SE telling you “See? The VPN fixed your internet!” and thus considering this issue fixed.

Yeah, this isn't a fix, it's a workaround at best. And even if the problem does prove to be slightly upstream from the FFXIV servers—which I still think is a possibility, because I've seen some Weird Things happen with misconfigured routers that are set up to rewrite packets for whatever reason—it's still going to be on them to fix; their ISP isn't going to listen to a random player, but would listen to SquareEnix.

I’m fresh out of ideas. You could check whether you’re connected to a different server through the VPN. If it’s a different server, that might indicate a problem with 204.2.229.93 itself. If it’s the same server, in b4 SE telling you “See? The VPN fixed your internet!”.

I'd also be curious to see if you're connected to the same IP address on the other end; you should be able to point Wireshark at the VPN interface (while the VPN is running, anyway) to sniff the traffic going across the VPN. If it isn't the same IP on the remote side, it suggests that the problem is specific to that server (and not necessarily just to you as a player).

If it is the same IP... well, then something is misconfigured somewhere, though without server logs it's basically impossible to know if that's the server on SquareEnix's end, or something slightly upstream from them. Either way, at that point, any further diagnosis is likely to have to be done by SquareEnix; I think we're about at the end of what Moronica or I can help you with, DA.

My gut feeling is still that something's misconfigured somewhere and the packet received by the server in the end makes it think you've gone away or stopped responding or sent an invalid command or something, thus causing it to consider the connection to have gone bad/been corrupted and closing it. But that's just gut feeling.

So… how many Square Enix employees does it take to check a server’s log???

To be fair, most forum CS folks do not have the authority or access to do such things. And most of the people who do don't read the forums. I'd be willing to bet that they don't have a good way to escalate forum tech support requests to the developers. They might have one for bug reports, but I suspect "misusing" that to escalate things which aren't bug reports could get them reprimanded; I've known folks who worked community support for game companies, and who had to operate under similar restrictions.

Either way, I would not be surprised if the people having connection issues is a situation that the devops team hasn't even been told about.

What I might try to do in this scenario is find the other folks who have had similar connection problems, and have them do the same tests. Are they connecting to the same server on the backend (204.2.229.93)? Is there any relationship between your origin IP address and theirs (i.e., in the same class B subnet or something)? Does a VPN solve the issue for them? Once you've gotten all their data and added it to yours, you have a nice packet of data that can be put together and smacked down in the Bug Reports forum with a repro case like...

Log into a character stored on the server at 204.2.229.93 from any of <Y> list of IP addresses, and you will witness consistent connection drops as shown in these Wireshark logs; the FIN flag on these TCP packets suggests the server closed the connection. Moving to another physical computer with the same origin IP (i.e., a second PC on the same home network) reproduces the same issue. Playing a different character on either computer will work fine, as long as the destination IP is not 204.2.229.93. Changing the origin IP by use of a VPN or proxy causes the issue to vanish, suggesting the issue is dependent on certain conditions in the incoming traffic. However, at least <Z> number of players are affected.

...or whatever.

At that point, it's at least in a nice bug-report bundle they probably have a process to escalate, and there's a nice tally of the affected people; hopefully that would be enough to get a response. Because unfortunately, much as we might wish otherwise, I doubt they're going to escalate a single instance of connection woes to devops, even if that instance says "other players are having similar problems" but doesn't list how many or who.

[Packetdancer]

Actually, I did think of one more thing. I don't know what your ISP is (or the hardware you have to connect to it), but if you have the ability to drop the DHCP lease and get a new IP address assigned to your router, I might try that just for kicks at this point. If that causes it to work, you definitely know it's something caused by the origin address. (And as a bonus, you would be able to play without VPN again!)

If it doesn't fix it, it doesn't give any new data, but it doesn't rule out past theories either; your new IP address might be in the same subnet as your old.

But at this point, anything else we try is mostly going to be just spitballing ideas and seeing what happens if we tweak any one variable in this connection.