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

[Moronica]

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…

[DoomAngel]

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…

I just did the Wireshark conversation filter >TCP to capture all sessions between those two IP's. Those two ports are the only ones that were open for that connection.

Regarding dropped packets, while playing the game and capturing data, I've seen packet loss and the game hasn't disconnected at times, and have seen the game drop during times without packet loss. *shrug*

[Moronica]

I just did the Wireshark conversation filter >TCP to capture all sessions between those two IP's. Those two ports are the only ones that were open for that connection.

Hmm… your 3 screenshots labeled Disconnect #1 through Disconnect #3 in your original post all show two TCP connections disconnecting. Your screenshot in another thread also shows two connections.

I have no idea whether it’s normal for a FF XIV client to have two connections, or it’s only two connections for a while after you change zone/dungeon/instance/whatever.

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