Quote Originally Posted by Packetdancer View Post
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.
The last screenshot only shows packets of one connection because Wireshark’s filter was “(ip.addr eq 192.168.1.146 and ip.addr eq 204.2.229.93) and (tcp.port eq 58899 and tcp.port eq 55026)”. Any additional TCP connection(s) from 192.168.1.146 to 204.2.229.93:55026 wouldn’t match these filter criteria.

There’s also no indication of dropped packets. The last two chunks of data sent by the client at 205.284423 and 205.296661 weren’t acknowledged by the server with an ACK most likely because it had already sent the FIN by the time it received those packets. That’s probably what caused the RST packets following the FIN, because received data can’t be acknowledged if the application already closed the socket and it thus unable to read that data.

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).

Someone™ has to check the logs of the server to figure out what’s going on…