Closed wolveix closed 1 month ago
Good Luck!
Might have found the issue, hold tight!
ok what did i miss? XD
Just in case you haven't seen it, I assume it's because of this:
LogHttpListener: Created new HttpListener on 127.0.0.1:7777
No, it's not because of that.
The API binds to a random port right now, looking for a config flag for it
You can get around the issue for now by running net=host
for the container
For those on docker-compose, that is network_mode: 'host'
, server works fine for me with this workaround.
I'll continue searching for the flag, assuming CoffeeStain added one that is
Can i somehow do that when iam using the docker image inside pterodactyl egg ? Or i need to wait for the author to fix it aswell ?
Can i somehow do that when iam using the docker image inside pterodactyl egg ? Or i need to wait for the author to fix it aswell ?
I'll fork the official egg and send a link in here for that
Okay, thanks.
You can get around the issue for now by running
net=host
for the container
Can't do this when you bind to a static IP on a different subnet, ideally we can configure the port manually.
by any chance, i deployed it on a truenas scale instance custom app, how do i change the network mode, if somehow someone know that
The network host workaround is not a one size fits all solution. If you are forwarding requests from one server to another, that's also an issue.
by any chance, i deployed it on a truenas scale instance custom app, how do i change the network mode, if somehow someone know that
You can't. One way to do it in scale, is to bind your container to the network bridge so it can get an IP address and then you connect to that IP.
The image only downloaded 60MB is this right? So the server from steam is 60MB?
How can I fix it when using Docker Swarm? I don't think network_mode: host
is an option there.
The image only downloaded 60MB is this right? So the server from steam is 60MB?
It will download the game server files on first launch
The image only downloaded 60MB is this right? So the server from steam is 60MB?
It will download the game server files on first launch
The container is running The container logs reported that he downloaded 60MB
@wolveix
From the official docs (found in game install dir):
Dedicated Server API consists of two separate endpoints, both operating on the same port as the game server, which is normally 7777. If the server port is changed (through Engine.ini configuration file, or through -Port= command line argument), the API will listen on the specified port instead.
The image only downloaded 60MB is this right? So the server from steam is 60MB?
It will download the game server files on first launch
The container is running The container logs reported that he downloaded 60MB
Folder itself is 4.1G which sounds more like it I don't know 🤷♂️ Maybe I am missing something
For future reference, these seem to be all available command options under unix, includes one for the http api -httpproxy=ADDRESS:PORT
.
@wolveix
From the official docs (found in game install dir):
Dedicated Server API consists of two separate endpoints, both operating on the same port as the game server, which is normally 7777. If the server port is changed (through Engine.ini configuration file, or through -Port= command line argument), the API will listen on the specified port instead.
Does not help me sadly.. running my server on port 2010 and still getting "Failed to Connect to the Server API" when joining using port 2010. Idk if i understood it right tho..
@wolveix
From the official docs (found in game install dir):
Dedicated Server API consists of two separate endpoints, both operating on the same port as the game server, which is normally 7777. If the server port is changed (through Engine.ini configuration file, or through -Port= command line argument), the API will listen on the specified port instead.
Where are you seeing these docs?
@wolveix steamapps\common\Satisfactory\CommunityResources\DedicatedServerAPIDocs.md
@wolveix
PATH\TO\YOUR\INSTALL\CommunityResources\DedicatedServerAPIDocs.md
Thanks guys!
Those docs don't seem to be right. It's completely disregarding the flags
My own with that set seems to accept it, but it doesnt do anything with it.. Weird.
[2024.09.10-15.59.54:814][ 0]LogOnlineVoice: OSS: Voice interface disabled by config [OnlineSubsystem].bHasVoiceEnabled
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: request failed, libcurl error: 56 (Failure when receiving data from the peer)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 0 ( Trying 50.20.249.105:2305...)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 1 (Connected to 50.20.249.105 (50.20.249.105) port 2305)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 2 (CONNECT tunnel: HTTP/1.1 negotiated)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 3 (allocate connect buffer)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 4 (Establish HTTP proxy tunnel to api.ipify.org:443)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 5 (Proxy CONNECT aborted)
[2024.09.10-15.59.54:815][ 1]LogHttp: Warning: 0x7f92a8869190: libcurl info message cache 6 (Closing connection)
As far as I can tell, there's just no way to specify the API port right now. The bind works for the game port, but not the API port
As far as I can tell, there's just no way to specify the API port right now. The bind works for the game port, but not the API port
Well i opened the port 7777, assigned it to my server but still does not work .. also tryed having the main port the same as the api port and also did not help .. still getting same api error when connecting..
So can we just change the game port and let the API port take 7777? I am not really understanding what the problem is, is there a port conflict?
Switching to host confirmed to fix temporarily the issue while the flag is figured out, thanks lads
The issue is that we can't configure the API port. That's it
Well shouldn't it work with the default one then ? (it does not)
There isn't a default port for it, it appears to dynamically bind at runtime
Yep, confirmed, it randomly binds on startup. Nothing I can do about it either until Coffee Stain fixes the issue, we find a secret flag to specify it, or...
Oh you know what it is?
root@satisfactory-server:/config# netstat -tulpn | grep LISTEN tcp 0 0 127.0.0.11:45629 0.0.0.0: LISTEN -
tcp 0 0 127.0.0.1:7777 0.0.0.0: LISTEN -
Seems your conclusion on a random http API port is correct. I connected to my Docker container, installed net-tools and checked for open ports. Apparently my HTTP API seems to be running on 45629.
Oh well thats ass .. so like on each restart it changes right ? Probably on an private machine opening all ports could work then .. but on commercial host machine it is not a possibility to prevent anyone getting in the machine ..
Logs are saying they are binding to 7777:
satisfactory-server | [2024.09.10-15.18.01:271][ 0]LogServer: Display: Generated a new Self-Signed certificate for the Server API (old certificate invalid or expired) satisfactory-server | [2024.09.10-15.18.01:271][ 0]LogServer: Warning: Server API is running using a Self-Signed Certificate. satisfactory-server | [2024.09.10-15.18.01:272][ 0]LogServer: Display: Server API listening on '0.0.0.0:7777' (Standalone)
So yeah, nothing we can do till the CoffeeStain devs fix this
Not finding anything in the config, docs, or anything online with any helpful information here. we quite literally just need coffeestain to release a fix
Hmm, my server logs show that the http server is running on port 7777, but it's bound to localhost rather than 0.0.0.0
. This would explain why setting network mode to host resolves the issue.
[2024.09.10-15.52.37:273][ 0]LogHttpListener: Created new HttpListener on 127.0.0.1:7777
[2024.09.10-15.52.37:273][ 0]LogServer: Display: Server API listening on '0.0.0.0:7777' (Standalone)
I think I've figured out a fix, one sec
In theory, we could have a script running inside the container, which would run netstat or similar, and once it sees the port listening, it could start up an internal proxy to connect X (configured) external port to the discovered internal port.
But that sounds like a lot of work and mess...
Lol, yeah sorry guys, my message a few messages back still applies.
In the log, it'll say that the API can't bind to 7777 as it's already in-use. So I figured, huh, I'll change the port to 7778 then. That "fixed" the issue in the log, but it doesn't actually change anything lol. So the game then binds to that port (instead of 7777), but the API still binds to a dynamic port.
So unless we find a secret config option (I don't think there is one, I think this is an unfortunate blunder on Coffee Stains' part), we can't do anything until they fix it.
In the meantime, you can get around this by running your container with network mode set to host
(details above)
I think I've figured out a fix, one sec
There a fix?
network_mode does not work with Docker Swarm 😭
https://steamcommunity.com/app/526870/discussions/1/4751949102181378614/?ctp=2
Interesting discussion in the Steam forums. It seems removing "-multihome=0.0.0.0" from a service file has fixed it for some. You then also get a certificate confirmation request first time you connect to the server since the server uses a random self-signed certificate for the HTTPS API.
we should not have multihome in the code anymore. it overridees things that shouldn't be now.
STATUS
IT WORKS 🎉
You shouldn't have any issues with the latest docker image. Available via the tags below:
latest
dev
v1.8.0
v1.8
v1.7.3
v1.7
You also need to ensure that BOTH ports 7777/udp AND 7777/tcp are port forwarded etc. You do not need ANY other ports.
If you see issues about the port binding in the log file, Coffee Stain confirmed to me that these messages are meaningless, please disregard them. The same goes for the certificate being self-signed. If you're getting a certificate key missing error when trying to join, make sure you've added the server through the in-game - server manager FIRST.
If you're unsure, please re-read the README before opening new issues. Every single person that has reported an issue since the fix went out either hadn't updated their Docker image, or were using the old Satisfactory ports.
Summary
I spoke with a Coffee Stain developer for a while and we troubleshooted together to figure out the issue. Essentially, there's an issue with how the TCP bind for the API disregards multihoming. You can reproduce the issue we see with the container by running it on baremetal with
-multihome
set to anything. No, we are not using-multihome
within the container. Yes, this is an issue we need to wait for them to fix.They've confirmed that the patch will be released in the next few days (week of September 9th)!