Issues, Workarounds & Localization

Very frustrated with this issue and the virtual silence from CCP.. Has been going on for over 2 weeks now and nothing! Tonight it took me 6 log-ins just to update my skill queue and barely got that off before my socket closed.

I have not been having this issue until today, now I get a black hanger background and a socket closed error moments later when docking frequently. Maybe one in every five station dockings I do.

socket was closed 10+times from yester day, change the port to 3724, can log in but 10mins again, try the mtr tools shows loss 50%+ through the server 62.115.14.113 dn-b3-link.telia.net, the webservice provider of CCP???
now lucky in the easy mission no dam on my shield even!

in this early morning, even lost my BS in the L3 mission, 19% hull remaining, just because of the FXXK socket was out, how about the next time, when in the PVP or corps combat

Definite bingo on port 3724 and that more or less confirmed my suspicion on a CCP client NAT (burrowing) issue. Thanks.
The _root_ problem is highly unlikely a carrier issue, because if it is, I'd be hearing a collective uproar coming from my side of internet.

Swapping to port 3724 resolved my _persistent_ black screen then socket closed after character selection issue.
No VPN workaround necessary atm. Now, let's see if port 3724 is stable.

Atm, I'm trying to figure out why port 26000 (Quake and other games also use this port) suddenly stopped working. My connection on port 3724 is robust and is back to normal as before.
This socket closed issue (right after the character selection screen) is 100% replicable (Rubicon patch 1.3.4 made no difference).

Quick check on a few online resource (gric.com/canyouseeme.org) confirms they were able to detect changes to port 26000 when in open state (port forwarded)/closed or stealthed state (dyn NAT). So, incoming/ongoing TCP/UDP traffic isn't likely blocked by the ISP. I can't confirm if there's any traffic shaping, but imo, it's highly unlikely that any would affect the EVE client. EVE is low bandwidth, latency tolerant (or did they tighten this timing in the client recently?). The major issue here is you simply can't get a proper test done since you have to eliminate routing due to the different paths. It's not 100% reliable. Calling the ISP is a ping-pong affair, I only do this if there's enough grounds/proof to show it's their problem, else it's generally a waste of time.

The most reliable test can only be done thru the route taken by the EVE client, SIMULATING its typical data transfer requests.

That brings me to this question. Now, I don't know if the EVE client has a built-in network diag tool that logs all messages under the log server. Thus far, CCP have relied on simple PathPing to troubleshoot network issues (afaik for their L1 support). Whats mind boggling, despite the long standing socket closed issues reports, no one at CCP has thought about writing a simple public test program that simulates & evaluates the typical client communication - everything from packet length, headers used, typical time outs etc. to HELP customers TROUBLESHOOT their issues.

Can it be that hard to write a simple custom network test program, preferably with its own dedicated CCP test IP?

Edit:
I'm sure this is already obvious, there are a couple of applications out there that can be used as a base or even code base for apps. Netcat and Ncat respectively.
Unfortunately, you need the proper public list server to reply to queries, else they're about almost useless. Various references seem to recommend Firebind (firebind.com) to fill this void, but again, it's limited to the pipe between Firebind's server and your client. It can probably serve as a base reference.

I pulled out Wireshark to check on the network traffic. Port 26000 is giving out multiple TCP Dup Ack (source 87.237.38.200) on one particular data frame. Earlier frames are fine, which would imply port 26000 to be working and valid. This isn't making complete sense atm. In comparison, Port 3724 traffic is as clean as a whistle (i.e. no errors that would imply TCP delivery issues). That deepens the mystery.

would you mind sharing a typical wireshark log (edited for confidentiality if required) so we can see and go deeper on this issue?

i don't have such issues so i can't see that behaviour on my side.

if you can't or don't want to share the log, could you check if the several "dup ack" are about the same packet?

there are supposed to be 3 / last Byte /packet to tell server he can send the rest, if the following "dup ack" sequence is for the same packet, then this might be that either the server didn't received the "dup ack", failed to send again the next packet, or you failed to receive it.

after a few retry, TCP will double the delay between 2 "dup ack" salvo

also, having "dup ack" means that some packets were lost in the first place.....

this can be seen by spotting [TCP Retransmission] request from you to the server

I'm suffering the socket closed problem recently. I thought it was caused by the submarine fiber cable disruption .
After I investigated this issue for a few days I found out that it should be blamed on ldn-b3-link.telia.net whose IP is 80.239.193.141. It's extremely unstable. The latency of it alternated between 210ms and 320ms. Sometimes it has no response.
And all the time out issues happend during the latency of 320ms.
And I also found out it happend many times before. There seemd no solution.

I can 2nd that.

63-291 with 2/10 pings time out.

for me it is in the regular folder, in my case:
C:\Users\Seth\AppData\Local\CCP\EVE\e_eve_tranquility\settings\prefs.ini