Devs please disable this server, to everyone else dont connect to it 54.170.20.117.19364

ollobrains

Banned
O
IP address 54.170.20.117.19364

This is the only server i keep having crashes with, market fails up, screen lags out all sorts of weird and wonderful disconnects and bugs with connecting with this server. the other 8 servers i connect to are clean as a whistle and dont have any errors, berfore the downtime i had a good run of 6 hours, after dt server ip address changed now im back to this buggy pile of rubbish and crashing left right and center, please fix it or disconnect it frontier

- - - - - Additional Content Posted / Auto Merge - - - - -

If others connecting to this server can check for errors, lag or any other funny business and post here if so, its the only common factor i can find
 

ollobrains

Banned
O
afte r9 times rebooting the launcher, finally got a server starting with 176. cant rmember the rest and logged in first go. Direct proof the servers are at play as far as some issues, others feel free to name and shame dodgy servers and post ueful ones
 

MikeSnos

MikeSnos
It's not the server that will be the issue in 99% of instances, it'll be an issue with another player connecting to the server that's affecting it... Have you sent a ticket to FD and sent your network logs for them to analyse?
 

deej

deej
It's probably not even a real server, but rather an VM instance. So if one is dodgy then they're all dodgy.
 

viperfan7

V
54.170.20.117 is located in New Jersey

There's no doubt their located in different parts of the world, the launcher probably connects first to a load balancer server, and that server tells the launcher what IP to use, there's probably start-up commands to even select what server you use directly for testing purposes
 

ollobrains

Banned
O
makes sense im in australia, the others might be a bit closer. And im playing solo so its not the instance of another player as per online play of p2p connection. Its a solo mode to one of fds servers
 

MARPATdroid

MARPATdroid
The servers used for matchmaking and directing instances are Amazon EC2 servers. Which means they are could VMs, and are able to be deployed on short notice almost anywhere in the world on short notice if you do a who.is on the server you can see where the server is located roughly, so far as the continent. If you know the governing authority for each region you can quickly tell where the server are, I know North America is ARIN, and Asia is APRIN, I'm not sure what South America, or Europe are.

Without further ado, here is the who.is for that IP, more or less to prove I'm not completely nuts. http://who.is/whois-ip/ip-address/54.170.20.117
 

DYSEQTA

DYSEQTA
Is this possibly related tomy current issue of all stations apparently not realy being there? Weird IDs "FSP #6400" instead of station name on entrance, can't see them in Contacts panel. Can't dock etc?
 

Yaffle

Volunteer Moderator
Yaffle
DYSEQTA said:
Is this possibly related tomy current issue of all stations apparently not realy being there? Weird IDs "FSP #6400" instead of station name on entrance, can't see them in Contacts panel. Can't dock etc?
Click to expand...

I'd ticket that!

Pressing ctrl+B wil show you the current bandwidth, if that remains at nil up and down then you can be sure there's a network gremlin at play.
 

Matt

M
Note that Geo lookups on IP addresses are notoriously poor.

For instance if I am sitting in my office in London my company's IP address ranges are registered in California, so doing a Geo lookup on my IP at that time would suggest "Hey this guy is in California!" when I am actually 5000 miles away.


If you do a reverse DNS look up on 54.170.20.117 you actually get ec2-54-170-20-117.eu-west-1.compute.amazonaws.com as the hostname. This suggests that it is in the Amazon EC2 EU West region which appears to be in Ireland (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)
 

DYSEQTA

DYSEQTA
Ok so I hate to admit it but my issue was a compound of an apparent bug and my own error. The no contacts thing was due to accidently turning my Sensor module off >.< The strange station name I have ticketed.
 

MARPATdroid

MARPATdroid
Matt said:
Note that Geo lookups on IP addresses are notoriously poor.

For instance if I am sitting in my office in London my company's IP address ranges are registered in California, so doing a Geo lookup on my IP at that time would suggest "Hey this guy is in California!" when I am actually 5000 miles away.


If you do a reverse DNS look up on 54.170.20.117 you actually get ec2-54-170-20-117.eu-west-1.compute.amazonaws.com as the hostname. This suggests that it is in the Amazon EC2 EU West region which appears to be in Ireland (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)
Click to expand...

Reverse DNS you over achiever, it's 4am my time so I'm not thinking 100% right now. Have some rep.
 

Demonic Squid

Demonic Squid
Ensign Ward said:
I've seen those IDs on some Federation stations. I thought it just meant "Federation Star Port number 6400", because I've seen names appended in addition to the IDs.
Click to expand...

Have seen this too. I have always assumed that they are just a station ID# and not indicative of a bug, after all they are cosmetic and the station name is often still there as well.
 

SnowGhost

S
deej said:
It's probably not even a real server, but rather an VM instance. So if one is dodgy then they're all dodgy.
Click to expand...

I don't think you know what you're talking about. Running any serives on bare metal servers now (as in 2014 or later) is just plain wrong. The only service you should run on the metal is a hyper Visor to allow virtualising the rest of your infrastructure. It allows me to run and support 80 or so servers across 11 sites on just 25 physical boxes.

And if "one is dodgy, they are all dodgy" is equally bogus. Unless you're referring to actual hardware, and that would be out of Frontiers hands, as their servers are running on top of Amazons systems. If there is faulty hardware, it doesn't take long for it to become very apparent. Mainly because the host won't boot, much less the guest OS's. Of course, the benefit then with virtual servers is you can just move the virtual machine to a different actual box with anywhere as little as zero downtime.
 

SquareHex

SquareHex
SnowGhost said:
I don't think you know what you're talking about. Running any serives on bare metal servers now (as in 2014 or later) is just plain wrong. The only service you should run on the metal is a hyper Visor
Click to expand...

That's just what he said, isn't it? It (the ED server) is a VM.

And one can assume that the ED servers are running the same configuration (even more so when they're templated VMs).
So it should follow that if one is 'dodgy' (has a bug), they'll all have the same problem.
 
You must log in or register to reply here.
Back
Top Bottom