Is it possible for the router firmware to close a port every 9 hours and 36 minutes?

[Squall Leonhart]

I'm currently trying to narrow down a disconnection bug in an online game i play, and i have narrowed it down to occuring every 9 hours and 36 minutes, no exceptions.

Yesterday and day before
[18:40:31] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : open
[04:16:29] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : closed
[04:17:20] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : open
[13:53:23] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : closed

Yesterday - Today
[16:19:28] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : open
[01:55:27] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : closed

[02:44] <gigaherz> 9 hours is 32400 seconds
[02:45] <gigaherz> sadly 36 minutes is too long
[02:45] <gigaherz> 34560 seconds total
[02:46] <gigaherz> 32768 = 9 hours, 6 minutes, 8 seconds
[02:46] <gigaherz> so.............
[02:46] <gigaherz> maybe it closes 30 minutes after it underflows?
[02:46] <gigaherz> err, overflows to negative

 

[ApexRon]

I'm currently trying to narrow down a disconnection bug in an online game i play, and i have narrowed it down to occuring every 9 hours and 36 minutes, no exceptions.

Yesterday and day before
[18:40:31] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : open
[04:16:29] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : closed
[04:17:20] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : open
[13:53:23] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : closed

Yesterday - Today
[16:19:28] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : open
[01:55:27] ffxiv_dx11.exe (18008) - ..*.48:55006 TCP : closed

Final Fantasy 14 TCP connections should remain open unless either end point drops the connection or there is a connection timeout caused by some type of issue with the physical connection between end points.

Is it possible that router firmware could close a port? Absolutely, anything is possible but unlikely. Since you have determined that the connection is closed every 9 hours and 36 seconds (34,560 seconds) I would rule out a physical connection issue. Sounds like a timer pop at either end point.

Assuming you are using a web browser at your end, does the PC have a static IP address? If not, it should.

 

[Squall Leonhart]

Yes, there is a static IP on this machine,

I'm on the fence between it being an issue specifically with recent updates to WTFast services, or some sort of issue with WTFast vs SE's DDOS countermeasures.

I have had ping plotter open and the particular data center im using never goes 100% return error, and while there are DDOS events going on atm, not seen more than 1.2% loss on a single hop, but a disconnection based on sustained packet loss would be completely random, i have chained these sessions 9:36:00 back to back and always hit a disconnect.

 

[ApexRon]

Yes, there is a static IP on this machine,

I'm on the fence between it being an issue specifically with recent updates to WTFast services, or some sort of issue with WTFast vs SE's DDOS countermeasures.

I have had ping plotter open and the particular data center im using never goes 100% return error, and while there are DDOS events going on atm, not seen more than 1.2% loss on a single hop, but a disconnection based on sustained packet loss would be completely random, i have chained these sessions 9:36:00 back to back and always hit a disconnect.

As I said, this appears to be a result of a timer pop. To pursue further I would recommend:

1. Review en.wikipedia.org/wiki/Transmission_Control_Protocol
2. Perform a packet capture of the session being closed

 

[Squall Leonhart]

2 will be next to impossible, assuming the issue is in WTFast, encryption is used and the client uses a anti-debug wrapper which will result in it closing off and probably not even restartable till a system reboot.

You've given me something to go on though, so thanks, this was not occuring prior to october 2nd if my memory is correct, so i'm narrowing down on that for now.