These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Issues, Workarounds & Localization

 
  • Topic is locked indefinitely.
 
Author
Jein Mai
Garoun Investment Bank
Gallente Federation
#481 - 2014-03-20 00:49:00 UTC
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.
Bezdar22
Destructive Influence
Northern Coalition.
#482 - 2014-03-20 12:24:50 UTC
Jein Mai wrote:
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.


1 pettion and ask for reimbursement. then in the mean time use crapy VPN
which is search and install ... very slow but will let u get in game
Bezdar22
Destructive Influence
Northern Coalition.
#483 - 2014-03-20 12:26:50 UTC
Yun Kuai wrote:
Yun Kuai wrote:
At first it started with 1 toon staying logged in while the other DC'ed to often to count; this happened for a couple days. Then it progressed to having one toon be able to log on, but the other just DC'ing on a black screen after selecting a character. Now, going on over a week, I've not been able to log on either character.

I can open the launcher and it loads just fine. It says that tranquility is online and the server is running. I log in and the game loads up slowly to the character selection page. I select my character and get a loading icon. The screen goes black and I get a socket closed message after 2 mins of being on a blacks screen.


To add some more information, I lived in China (I'm not Chinese so no I won't play on Serenity servers) for 3 years now and this is the first time I've had this issue. I get the occasional DC to the stupidly slow internet speeds, but this is the first time I've not been able to actually log on. Also, the whole contact your ISP and get them to come out isn't plausible (you think customer service is bad back home....) considering the network requirements and language barrier.

Please help, I'm having EvE withdrawls....



Well update time:
I've multiple times throughout each day to connect. This evening I attempted to log in, same thing showing as above showing that everything should be working fine, except now it's gotten even worse.

Now, I open the launcher and log in (says Tranquility server is online and doing well), the game client opens but I'm DC'ing before the character selection screen now Shocked

VPN
which is search and install ... very slow but will let u get in game
HALP!!!!

Maximum Entropy
Entropic Principal
#484 - 2014-03-22 04:37:28 UTC
I have been having socket disconnects for the last couple weeks.

Tonight, I warped into a Mordus Headhunters level 4 mission, and when I landed activated my bastion module. It didn't activate. Client quit responding, and eventually I got the "Socket disconnect" error message window.

I tried logging back in as fast as possible, but it was too late. My vargur was destroyed (1.3 billion loss.)

Too much dps too fast, before the server warped me away.

I had no isk, and that vargur was the only way I had to make isk, so I'm hoping that CCP will reimburse it.

Why is the total number of "likes received" a poster has inversely proportional to the quality of posts one makes?

Abyss Azizora
Viziam
Amarr Empire
#485 - 2014-03-22 07:45:15 UTC
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.
Yun Kuai
Garoun Investment Bank
Gallente Federation
#486 - 2014-03-22 17:51:10 UTC
Confirming that yesterday I was able to log in for about 30mins before not being able to log in again. I managed to kill a dramiel so that was okay, but I'm still essentially going on 2 weeks of not being able to play.

Still getting the same thing of everything showing EvE should be up and running just fine, logging in to the character selection screen (sometimes not even that far), and then just black screening until the socket closes...

I've petitioned CCP about it, it's being taken to a senior GM at the moment so I'm just waiting for a response from them. I seriously hope there is something done about this soon

--------------------------------------------------------::::::::::::--:::-----:::---::::::::::::--------------:::----------:::----:::---:::----------------------:::::::-------:::---:::----::::::-------------------:::-----------:::--:::----:::---------------------::::::::::::----:::::::----:::::::::::::-------

Alexader Shinne
Viziam
Amarr Empire
#487 - 2014-03-23 06:02:23 UTC  |  Edited by: Alexader Shinne
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???PiratePiratePirate
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
Syrix Death
24th Imperial Crusade
Amarr Empire
#488 - 2014-03-24 16:14:48 UTC  |  Edited by: Syrix Death
Someone tried already this one:
https://wiki.eveonline.com/en/wiki/Problems_connecting_on_port_26000

EDIT:
I tried this solution and seems like I can play now without any workaround

DO this one:
nedit /home/$USERNAME/.wine/wineprefix/$EVE/drive_c/users/$USERNAME/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/settings/prefs.ini

replace
...
port=26000
...

BY this one:
...
port=3724
...
Sturmwolke
#489 - 2014-03-25 08:40:03 UTC
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.
Yun Kuai
Garoun Investment Bank
Gallente Federation
#490 - 2014-03-25 10:12:14 UTC
Sturmwolke wrote:
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.



Confirming that I was able to log in for about 5mins before DC'ing again so I wouldn't say very stable at all Ugh

--------------------------------------------------------::::::::::::--:::-----:::---::::::::::::--------------:::----------:::----:::---:::----------------------:::::::-------:::---:::----::::::-------------------:::-----------:::--:::----:::---------------------::::::::::::----:::::::----:::::::::::::-------

Sturmwolke
#491 - 2014-03-25 17:22:24 UTC  |  Edited by: Sturmwolke
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.
Alexader Shinne
Viziam
Amarr Empire
#492 - 2014-03-27 13:39:56 UTC
OopsOopsOopstoday the game speed was so perfect,but suddenly socket closed again when in the ugly mission My Sweet Privateer, no reason ping result loss <10%...just the chat from corp!!! Who tell me Why???
seth Hendar
I love you miners
#493 - 2014-03-27 14:22:48 UTC  |  Edited by: seth Hendar
Sturmwolke wrote:
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
Sturmwolke
#494 - 2014-03-28 12:21:04 UTC
seth Hendar wrote:
[
would you mind sharing a typical wireshark log (edited for confidentiality if required) so we can see and go deeper on this issue?

Best I'm willing to share publicly is a screenshot Blink

http://i.imgur.com/AQjZp0O.png

one more thing, port 3724 data is mostly done using the WOW network protocol (apparently the old Wireshark version I was using didn't see this).
[see - http://dvlabs.tippingpoint.com/blog/2007/06/28/decoding-the-world-of-warcraft]

that's a significant difference!

Traffic shaping is still on the table, but here's the thing, my BitTorrent on port 26000 works as per normal when tested (it's usually on another port).
It also doesn't make any sense when you consider it fails persistently after every character selection screen, not randomly.
Nate Hill
Rocket No. 9
#495 - 2014-03-29 00:58:59 UTC  |  Edited by: Nate Hill
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. Sad
Jhan Khatar
Republic University
Minmatar Republic
#496 - 2014-04-05 19:14:33 UTC
Can anybody tell me where prefs.ini resides on Windows 8?
Yury Isko
Imperial Shipment
Amarr Empire
#497 - 2014-04-07 18:07:54 UTC
Nate Hill wrote:
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. Sad



I can 2nd that.

63-291 with 2/10 pings time out.
seth Hendar
I love you miners
#498 - 2014-04-08 10:33:50 UTC
Sturmwolke wrote:
seth Hendar wrote:
[
would you mind sharing a typical wireshark log (edited for confidentiality if required) so we can see and go deeper on this issue?

Best I'm willing to share publicly is a screenshot Blink

http://i.imgur.com/AQjZp0O.png

one more thing, port 3724 data is mostly done using the WOW network protocol (apparently the old Wireshark version I was using didn't see this).
[see - http://dvlabs.tippingpoint.com/blog/2007/06/28/decoding-the-world-of-warcraft]

that's a significant difference!

Traffic shaping is still on the table, but here's the thing, my BitTorrent on port 26000 works as per normal when tested (it's usually on another port).
It also doesn't make any sense when you consider it fails persistently after every character selection screen, not randomly.

thx, exactly what ithought it would look like, sorry if i missed this, but did you check your path to the eve server, and if at some point, one hop is having massive packet loss? (could be interesting to do while playing eve and look right after you encounter the issue).

you could use pingplotter wich is easier to manage and see issues on long runs
seth Hendar
I love you miners
#499 - 2014-04-08 10:35:41 UTC
Jhan Khatar wrote:
Can anybody tell me where prefs.ini resides on Windows 8?

for me it is in the regular folder, in my case:
C:\Users\Seth\AppData\Local\CCP\EVE\e_eve_tranquility\settings\prefs.ini
W0lf Crendraven
The Tuskers
The Tuskers Co.
#500 - 2014-04-12 14:51:28 UTC
Had the same problem (sicne february), the pref.ini thing worked. For tq, anyone know how to make it work for sisi?