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.
 

Socket Closed - Launcher only

First post First post
Author
Previous Topic Next Topic
Helios Anduath
The Scope
Gallente Federation
#241 - 2016-03-13 12:58:26 UTC
Tipa Riot wrote:
[quote=Helios Anduath]
Since I left university I became a late adopter of stuff I actually need to work flawlessly. Blink Probably this is the RL equivalent of a carebear. Lol Nevertheless no closed sockets yesterday, PvPing all time (null roam, gate camp, 250 player fight in lowsec) since downtime. The difference: the launcher was closed and I had ping -t running in the background (for half of the time).


Interesting. Just for verification, can you check that the disconects still happen with launcher open and no ping.

Can you post a screenshot of a Pingplotter running to client.eveonline.com taken just after a socket closed event (looking back, I can't see one posted)

Does playing through a VPN stabilise the issue without a ping running?
Napolk Kosh
Spoofe Investment Corp
Memento Moriendo
#242 - 2016-03-13 13:37:04 UTC
Helios Anduath wrote:
Napolk Kosh wrote:
So according to PingPlotter when set to client.eveonline.com I get a 26 to 49% Packet Loss when it goes over from my ISP to CCP's Level3 Communications ( 62.140.27.5 ) is this the reason I keep getting Socket Closed on some account and not on others?


Could you actually post a screenshot please? preferably taken just after a socket closed event. The reason being it is easier to analyse an image and it also shows us what route your traffic is taking so that we can see if there are any similarities among people having issues.

Packet loss in a ping/traceroute on a single hop that does not propagate along the route is not in itself a problem - it just shows that the node dropping packets is probably loaded and prioritising passing traffic rather than responding to ICMP requests. If the packet loss propagates, then that is indicative of a problem at that node.

Is it the reason? maybe, maybe not - we need to do some more diagnostics.

Does playing through a VPN stabilise things?


Here's a Pingplotter with some hours on it and a few Socket closes.

http://imgur.com/df6Iv30

I tried running with VPN did not solve the issue with Socket Closes.
Helios Anduath
The Scope
Gallente Federation
#243 - 2016-03-13 13:53:42 UTC
Shade Millith wrote:
Opened 5 clients on Singularity server with the Wired connection. Idle clients had no lag, no unresponsiveness, updating perfectly fine, even after idling for 20+ minutes.

Jumped back and forth between Sisi and Tranq a couple of times. Idle clients on Tranquility stop updating within minutes. Idle clients on SiSi are 100% fine.

Also, I made an edit to the previous post. Router reset removed the IP flipping.


That is strange - your router has no effect on the route your traffic takes further up the pipe. How routing works is that each router only knows the next hop where it is sending its packets - e.g. Router 1 only knows to send to Router 2. It is up to Router 2 to determine where to send it next based on the destination IP address.

While interesting that it works to Sisi but not TQ, it does not definitively say that there is a problem on CCP's side especially when combined with narrowing it down to it manifesting on your wired interface on the router only. It does say that there is a difference between the two, and that is expected as the traffic between SiSi and TQ will be subtly different (IP address ,etc.) which might be enough to not trigger the issue.

What might be a good test is to do another wireshark packet capture but with the capture filter of "net 87.237.32.0/21" to capture anything going to/from CCP's servers.

Another interesting one would be a wireshark capture of everything and then apply with a display filter of "(icmp.type > 0 and icmp.type < 8) or icmp.type > 8 or tcp.analysis.flags or _ws.expert.severity == error" (this gets us just TCP oddities, ICMP errors and other odd foo). It would still be good to have as little in the way of network apps open

Unfortunately seeing actual dodgy packets (that fail CRC check, etc.) is not that easy to do, and consumer network hardware tends not to log interface error counts in an accessible way, if at all. Windows has also made it hard to view interface errors, but you can enable them for some adapters with this guide. What am I getting at here? well, an interesting test would be to see if there is a spike in the number of interface errors at both ends with multiple idle clients open. Not an easy one to obtain though.
Helios Anduath
The Scope
Gallente Federation
#244 - 2016-03-13 14:05:49 UTC
Napolk Kosh wrote:
Here's a Pingplotter with some hours on it and a few Socket closes.

http://imgur.com/df6Iv30

I tried running with VPN did not solve the issue with Socket Closes.


OK, so the big packet loss spike at that Level3.net hop is not an issue in itself as it does not propagate. Also, just for clarity that hop is nothing to do with CCP - your ISP either peers with Level3.net or uses them for transit. CCP peers with level3.net (along with many other providers) on their end to give lots of potential routes in.

What is of concern on that pingplotter is the packet loss starting at hop 2 that propagates all the way to the end. This is indicative of an issue with the connection from your router to your ISP and should not be there. You should probably contact your ISP to try and get the packet loss resolved and then see if the socket closeds continue once the issue is resolved.

Where did you try connecting to for a VPN? it is probably worth trying with a couple of different ones.
durazell
Caldari Carebears
#245 - 2016-03-13 21:00:46 UTC
For the first time ever I downloaded the test server client. It seems my connection stays 100% alive on test server !?
Problems for me continues on tranquillity. ALWAYS disconnected/socket closed after 5-10 min of being idle in station or space.

Then I tried 7 days trial VPN from Avast antivirus. It works fine and Im NOT disconnected on tranquillity. (chose the Frankfurt server)

Then i downloaded the pingplotter. Since my disconnect is absolute and almost schematic, it only took a few minutes to make 2 screen shots a few seconds after disconnection.

http://imgur.com/a/6DAyf

I am a technical retar.d Big smile but luckily I am surround by experts in this fora.

What can I say; I have a standard 50/50 fiber solution, an ISP owned router mounted on my wall and I use wifi.
Helios Anduath
The Scope
Gallente Federation
#246 - 2016-03-14 01:40:31 UTC
durazell wrote:
For the first time ever I downloaded the test server client. It seems my connection stays 100% alive on test server !?
Problems for me continues on tranquillity. ALWAYS disconnected/socket closed after 5-10 min of being idle in station or space.

Then I tried 7 days trial VPN from Avast antivirus. It works fine and Im NOT disconnected on tranquillity. (chose the Frankfurt server)

Then i downloaded the pingplotter. Since my disconnect is absolute and almost schematic, it only took a few minutes to make 2 screen shots a few seconds after disconnection.

http://imgur.com/a/6DAyf

I am a technical retar.d Big smile but luckily I am surround by experts in this fora.

What can I say; I have a standard 50/50 fiber solution, an ISP owned router mounted on my wall and I use wifi.


Firstly, is it a single client that you are running that gets DCed after the idle period or is it other clients that you are running that don't have focus?

Those pingplotters are showing that there is some packet loss that propagates (inconsistently) along the network. How closely did the disconnect line up with the big red bars at the end of those plots?

Could you just try leaving pingplotter running for a longer period (you don't have to have the game running) with the trace interval set to 1s as I am interested in seeing exactly which hop the packet loss starts on - in those two screenshots, it starts on different nodes both owned by TreFor.

From those plots, the "local" hardware doesn't look to be a problem (though I cringe at your ISP's setup as they are seemingly making you go through multiple levels of NAT which is just plain nasty and can cause it's own issues for other things) but testing on Ethernet is not a bad idea just for completeness.
durazell
Caldari Carebears
#247 - 2016-03-14 21:51:41 UTC
It seems that the DC issues I had with the eve client was on my shoulders entirely:

A friend of mine came by and had a quick look at my network setup.He noticed that I had a specified dns address active in properties for the TCP/ IPv4. Where it came from Cool I dont know and it was changed to retrieve dns per auto.
After that change I havnt been disconnected at all when logged into my eve client. Cable or wifi.
Still I am pretty sure that I had these DC issues ever since feb 29 and perhaps a week earlier. I play eve very often so this DC gets noticed right away. pingplotter just after the change using ethernet cable while eve client is running. Btw I only use 1 client on my PC.

Anyway Helios Anduath thx for bothering, I just might throw som fireworks in yer face if I se ya ingame -> omw to launcher.
Helios Anduath
The Scope
Gallente Federation
#248 - 2016-03-14 21:57:41 UTC
durazell wrote:
It seems that the DC issues I had with the eve client was on my shoulders entirely:

A friend of mine came by and had a quick look at my network setup.He noticed that I had a specified dns address active in properties for the TCP/ IPv4. Where it came from Cool I dont know and it was changed to retrieve dns per auto.
After that change I havnt been disconnected at all when logged into my eve client. Cable or wifi.
Still I am pretty sure that I had these DC issues ever since feb 29 and perhaps a week earlier. I play eve very often so this DC gets noticed right away. pingplotter just after the change using ethernet cable while eve client is running. Btw I only use 1 client on my PC.

Anyway Helios Anduath thx for bothering, I just might throw som fireworks in yer face if I se ya ingame -> omw to launcher.


You are welcome and I always gladly accept fireworks, it is just a shame I have not had the time to really log in recently.

I am glad that your issue seems to have been resolved BUT that setting should not have had any effect at all - having a DNS server set (this is where your computer goes to look up what IP address a given name has) would not cause packet loss. Your issue may come back - if it does, I will happily do some more troubleshooting with you.
Ravcharas
Infinite Point
Pandemic Horde
#249 - 2016-03-15 19:44:56 UTC
Ok, so today has been a bad day for sockets. All of my accounts have disco'd. Doesn't matter if I singlebox or dual-wield. Sometimes two out of three goes at the same time, sometimes one by one. Sometimes the active account goes, sometimes the idle ones.

I think maybe I finally caught something on this pingplot thing though. http://i.imgur.com/z719WSv.png

Though I can't quite figure out the rhyme or reason to which account goes when, looks like something's fucky in the intertubes.
Ravcharas
Infinite Point
Pandemic Horde
#250 - 2016-03-15 20:45:05 UTC
Yeah there it went again, this time without any red dangerbars. I give up.
Helios Anduath
The Scope
Gallente Federation
#251 - 2016-03-16 02:22:35 UTC
Ravcharas wrote:
Ok, so today has been a bad day for sockets. All of my accounts have disco'd. Doesn't matter if I singlebox or dual-wield. Sometimes two out of three goes at the same time, sometimes one by one. Sometimes the active account goes, sometimes the idle ones.

I think maybe I finally caught something on this pingplot thing though. http://i.imgur.com/z719WSv.png

Though I can't quite figure out the rhyme or reason to which account goes when, looks like something's fucky in the intertubes.


Sounds like it has been behaving differently to what you mentioned before?

so, on that pingploter, the big bars at hops 8 and 9 are not an issue themselves because that level of packet loss has not propagated to the end of the route - those nodes are probably quite loaded and prioritising routing traffic over responding to/with ICMP.

What is interesting is that 0.1% packet loss that starts at your router and is present along most of the route (it not appearing everywhere is possible because of the interval pingplotter uses). That implies that there might be something to do with your local network causing issues, and this would fit with the change in presentation.

How do you connect to your home network? is it wired of WiFi and is it possible for you to test with the other?

Does playing through a VPN stabilise things for you?
Ravcharas
Infinite Point
Pandemic Horde
#252 - 2016-03-16 10:09:57 UTC
Helios Anduath wrote:
Sounds like it has been behaving differently to what you mentioned before?

so, on that pingploter, the big bars at hops 8 and 9 are not an issue themselves because that level of packet loss has not propagated to the end of the route - those nodes are probably quite loaded and prioritising routing traffic over responding to/with ICMP.

What is interesting is that 0.1% packet loss that starts at your router and is present along most of the route (it not appearing everywhere is possible because of the interval pingplotter uses). That implies that there might be something to do with your local network causing issues, and this would fit with the change in presentation.

How do you connect to your home network? is it wired of WiFi and is it possible for you to test with the other?

Does playing through a VPN stabilise things for you?

Yeah yesterday was double-plus crazy.

The router packet loss is strange, yes. Although it's not representative of how it usually looks, I must say. Right now I logged on a second character and it got disconnected after mere minutes. This is the pingplotter for that event; http://i.imgur.com/NyTuJmV.png I can't rule out that it's my equipment, of course, but usually I don't see any packetloss that early in the route.

I'm wired all the way. I guess I could dig up some ten year old wireless usb thing maybe, if I go spelunking in the cardboard hell of the closet. VPN I haven't tried yet. It's next on my list if this keeps up.

(Aaand another one just as I was finishing this post up; http://i.imgur.com/WHzzy54.png First character stays logged on no problem.)
digger70
Kenshin.
Fraternity.
#253 - 2016-03-17 14:37:52 UTC
its been nearly 3 weeks now without being able to play i am nearly ready to unsub but i really love the game very disappointing :) 4 accs 4 100mil sp toons
Iguanoid
Ascendance
Goonswarm Federation
#254 - 2016-03-18 16:29:54 UTC
I have had an open ticket about this for 2 weeks now with no response. Pingplotter screen grabs attached in the ticket show no packet loss.

This doesn't seem to happen if i am actively doing stuff, but if i afk for 5 minutes i am almost guaranteed to come back to a socket closed message.
Panther2707
Exit-Strategy
Minmatar Fleet Alliance
#255 - 2016-03-19 05:16:52 UTC  |  Edited by: Panther2707
Helios Anduath wrote:
Panther2707 wrote:
Using a sydney server for VPN, first log is the route from me to the VPN, second log is from the VPN to the server. No issues at all last night, probably added another ~100ms to my ping but being australian im already used to high ping so its manageable until the issue clears.


Cool, that shows exactly what I would expect for a VPN that stabilises things - you take a completely different route in to the server.

Latency wise, it looks about the same. Your no-VPN pinplotter was showing 337ms, this tracert was showing 343ms so you have gained 6ms. That is not bad if it stabilises things.

I would suggest you keep an eye on things and try without the VPN once the cable faults in the area have been repaired.


So as an update, the issue still remains without a VPN, ran ping plotter 2 days ago and ran a test again today, no packet loss appeared for both socket closures.

http://imgur.com/7d8dI4r - screenshot from 2 days ago

http://imgur.com/cgtVSZP - Tried it again today not long before this post.

Tried playing on singularity with no VPN, didn't have any connection issues at all, so its unlikely to be a local issue here.

You wouldn't happen to know if the undersea cables have been fixed at all? last i heard they were scheduled to be fixed late last week, though i cant find much info on it.
Quantos Peak
Caldari Provisions
Caldari State
#256 - 2016-03-20 05:26:45 UTC
Well, this is a mess isn't it? Of course there doesn't seem to be a single cause to all these issues, but I still find it hard to believe that a seemingly sudden increase of occurrence of this issue is completely unrelated with some change CCP have done at some point in the past few months. Perhaps it's a patch, or a server change.

Anyway, I've been experiencing this issue for a number of weeks now. I didn't make much of it for some time, so it's a bit hard to say exactly when this started to happen.

There are a couple of things that I have found.

First, numerous pinging and tracert tests have found no issues with my local server, or ISP connections. Some nodes along the way do show some packet loss, but none of it propagates to the end, and I'm always able to reach client.eveonline.com.

Now, there obviously are servers to reach other than client.eveonline.com (which is 87.237.34.202). Packets are being sent and received from 87.237.34.200 and 87.237.39.53. These are the ones that will fail when the connection is closed.

The type of connection to these two IPs is different. From what I can see the connection to 87.237.39.53 is SSL and consists of SYN packets over port 443. On the other hand, the connection to 87.237.34.200 is made over port 26000.

Just before the socket closes, these two connections will fail in different ways: http://i.imgur.com/DW5w8j6.png

The spurious retransmissions specifically are kind of a headache. I'm far from an expert in network analysis, but a brief read tells me that this type of retransmission happens when the source and destination do not agree on the state of the connection. In this case it looks like the CCP server is trying to reset a connection while I'm sending the retransmission for another. The fact that the retransmissions are spurious indicate that as far as my computer is concerned, that connection is valid and has already been acknowledged.

What exactly all of this means is hard for me to figure out. These TCP failures could certainly be related to something on my side or on CCP's, but they can be just as easily be related to something anywhere inbetween. There's just no way to tell. The bottom line simply is that at some point I'm sending information to the CCP server and it is either never received by CCP, or somehow handled incorrectly.

One thing I did try to mess around with is the limit of retransmissions that Windows will attempt before it considers a connection dead. By default, it will attempt 5 times, which happens over a pretty short period of time (roughly 15 seconds, but I believe the exact span of time depends on the quality of the connection). I was trying to find a way to increase the number of times it would attempt to retransmit, just to see if after a longer span of time I would get a response from CCP. However, while there is an easy regedit key to edit for this in Windows 7 and 8, it seems to be missing from Windows 10. I couldn't find a way to modify this in Windows 10. Now, maybe this is moot, as I'm not sure if this socket issue is OS-specific, but maybe it's worth taking a look at.
Enn DeeKay
Sebiestor Tribe
Minmatar Republic
#257 - 2016-03-20 21:42:06 UTC
3ulldog wrote:
After putting in more Petitions and then Petitions saying this is a Bug and please submit to Bug dept, today after 11 days waiting i receive a reply from Bugs Dept:

Bug Hunter
Thank you for your bug report. Unfortunately it appears that this issue falls under the remit of our Customer Support department. Please resubmit your issue via the following link for immediate attention from a Customer Support representative: https://ccpcommunity.zendesk.com

o7

So now i am being told to go back to Petitions.

It would seem nobody in CCP wants to get involved in sorting this problem,
I have paste this forum thread in multiple petitions and bug reports so they must know this is going on.


At least you received a reply, 3ulldog. I'm waiting 21 days to receive a human response from the CCP Customer "Support" department. As far as I'm concerned the acronym CCP when applied to Customer Support means: Can't Communicate Properly!

Appalling lack of service to loyal customers. 21 days of frustration, testing and thousands of logins with reports to CCP on what must be one of the longest support threads ever. But I've had the same issue before where over a year ago it took 21 days before a human response was received.

They could have just linked me to this forum thread and/or to CCP Gun Show's statement with a simple reply acknowledging the issue. But no I had to find this information from an alliance mate.

That's not customer service or support by any means or stretch of the imagination. In any business that provides such an appalling level of "support" needs to look to its leadership to get this corrected, or the fall will be hard, fast and permanent.

Clearly CCP Support has a Systemic Internal (cultural) Issue when it comes to actually providing Customer Support. The new Chief Customer Officer Maria Sarans will have her work cut out for her to fix this. https://www.ccpgames.com/news/

EVE is a great game, and its players put up with a lot of issues every year but are let down by the long term systemic failure of its Customer Support department.

Time for CCP to get this department overhauled and actually communicating and servicing its loyal paying customers.
durazell
Caldari Carebears
#258 - 2016-03-22 14:51:00 UTC
DAMIT Smile Im back again after 3 days with no disconnection issues at all. There was a small fix 18mb or so some days ago, but not quite sure. Then these DC issues were all over me again. Being idle for approx 5 min and Im disconnected WITHOUT exception. After checking all of my network settings and shifting between different routers; Alcatel, Cisco, tomato, ethernet cable, wifi etc, I did probaly 100 tests with pingplotter. The results of these tests (using a noobish freeware tool and the fact I know **** about this issue) my own conclusion is pretty clear: There is nothing wrong with my ISP or my connection.
All of my programs on my PC, games, playstation, chromecasts, apple tv, tablets, ipads cell phones etc are just all rocking and streams/connects/keeping alive like a dream. Only the eve client disconnects.

Either I have a hardware/software issue OR anything imaginable could be wrong on the other side.

Take a look at these pingplots during several disconnects; they look like at network analyst wet dream; low ping, horizontal graphs, no significant spikes AND absolutely nothing to see during the DC. Not ONE single packet loss during these 40 min of testing.

http://imgur.com/a/FjjBS

Yesterday I checked my connection using pingplotter againagainagain and noticed that my route had changed; 2 further hops added (telia). Acc to pingplotter this improved my connection even more and ping fluctuations are now much more narrow all the way down the hops. I was thinking hurrah until I got disconnected after 5 min of being idle in station !

http://imgur.com/VPOsKNH

So now I am on VPN when playing eve and its working very well so far. So well, that I really cant tell the difference. However I would rather use my money on plex instead of a VPN subscription wouldnt you agree ccp Lol ?

This is a pingplot of my VPN connection during eve gameplay which keeps my connection 100% alive:

http://imgur.com/hdsKfGf

Montgomery Black
Brutor Tribe
Minmatar Republic
#259 - 2016-04-13 08:05:23 UTC
This really needs to get fixed.

I idle DC within 5 mins consistently across all accounts. The only thing that prevents it is refreshing dscan.

Whats worse.. within 5 minutes my clients lose synch with the game server and until I press dscan nothing updates..

A ship could be shooting me and I could be dying but I wont know until I press dscan... cause then it will magically appear on grid and have me scrammed and in structure.. Roll

This all started happening after the Tranquility server upgrade and move.

WH Merc Services in AU TZ. Citadel defense / offense. More details see forum post - Link
Panther2707
Exit-Strategy
Minmatar Fleet Alliance
#260 - 2016-04-21 09:38:38 UTC
So something interesting Mont found last night, when he played with the Help channels open (they were used since the chat is usually active) he did not disconnect once or have the client go out of sync for a full night. I tried it myself, i was able to remain connected to the game with no issue, though within 10 minutes of me leaving the channels i got socket closed.

Not sure what would cause the socket closed issue in the first place, though by staying in the help channel and having constant communication with TQ seems to help, though I do find it strange that I don't get socket closed at all while using a VPN.

I'd assume any active channel would work, the help channel was used in this case due to the constant chat.