Ongoing login issues!

I had this, from DT until about 10 minutes ago. Couldn’t log in to anything, not even here. SIS was OK though. I did send all the logs to CCP. Still haven’t had any reply.

You may find if you run the tracer route the problem is not at CCP. It’s like the connection before it gets to CCP. Or something like that.

I’ll bet if you were to use a VPN it would log you right on because the whole routing would be different.

Go to that settings thingy in the upper right of your launcher. Click on Network Diagnostics and then pick Traceroute.

Well… I didn’t run a traceroute that day to prove that there’s something fishy with them. Just take a look at a traceroute (in general). If you own 2 dns servers you can always manipulate the output from traceroute - 1st going to 2nd and so on, and you manipulate the response from 1st (e.g. it times out in a certain situations) - thus you get a “network error” so - no reimbursement.

My connection is flawless and I have a great uptime.

The thing is - I don’t know what systems of prevention and handling DDoS attacks (it’s quite impossible to defend and maintain accessibility to users/players). When you get to the point that you’re getting hammered by DDoS, you got to be honest and compensate for players loses. I have to emphasize that it’s just in-game money for them - no real money loss.

I still can’t log in all day today. Is anyone else still experiencing issues?

oh yeah.

What the hell. At least provide some feedback. Can ui get a refund as i have been unable to play since 2 days ago?

I also can not log in west coast US. was playing fine this am now it keeps going could not connect to login server.

Then how does local know what system you’re in?

There has to be information from TQ getting to the chat server or else… yeah. Well, maybe that explains seeing different numbers of pilots/pilot names in local on different toons at the same time in the same system after all, then.

And again today getting a “cannot connect to login server” or the account website again. what is going on guys?

I am connecting via a steam account if this matters and I am able to log in to the test server… which is even weirder.
Would really appreciate some correspondence regarding this as i cant even access the support page to file a bug report. Derp

I’ve been unable to connect to login server for hours now…

my primary account is via steam as well (with its own independent login) and I was able to log in to TQ on it + 2 alt accts earlier today (shortly after downtime), went AFK 6 hours, came back, still on. But I haven’t closed launcher since then, so… thanks for the heads up.

I think as others in this thread have said, tho, that it matters more where you are geographically (IP-address-wise) than it matters how you’re connecting. It’s the DDoSers’ fault.

Interesting stuff, Im UK based if that helps to correlate with anything else you’ve read?
Up until a minute ago I wasn’t aware you could submit a support ticket without actually logging into the support page so fingers crossed between everyone’s logs they can work something out.

Same here. Could not connect to login server in launcher, SSO status check received connection refused from https://login.eveonline.com/version in launcher logs. Both secure.eveonline.com and login.eveonline.com are timing out in browser. Via VPN everything works as expected. I am in Germany.

1 Like

Curious… I’m in the UK too. I’ve been logging on and off all day, and haven’t seen any problems at all.

1 Like

Appears to working again, for me atleast.

TQ don’t need to know that… TQ relays to the client where you are at now and when you jump a gate it relays where are you going to be and the client connects to the corresponding local “room” in the chat server… easy… now you can spam local all you want and TQ stays nice and calm…

Login server doesnt work for over 30min, ccp plz say smth

Okay, but if TQ relays to your client information and then your client relays it to the cloud chat server… that’s still info from TQ going to the chat server.

There’s just a MITM (man in the middle) as well.

It is a information that your client already has to receive in order to function and it is only relayed once, TQ don’t need to deal with anything related to the chat system… your client and the chat server does all the heavy lifting dealing with this load.
The ideia behind this is that one service being hammered down will not interfere in others (Microservices Architecture) … and my original point was “No, the new chat system/server cannot interfere in the stability of TQ because it is a isolated system”

ps: Isolated does not mean “Immune to problems” just that those problemas cannot generate other problems somewhere else