satisfactory-server
satisfactory-server copied to clipboard
1.0 container / server process not listening on IPv6
Not sure if this is a material change to the image, or something in the game server itself with 1.0. It appears the server process no longer listens internally on IPv6 regardless of the SERVERIP environment variable. This behavior continues even after the current 1.0 game hotfix and workaround removal from the image.
Exec'd into running container & ran apt update && apt install net-tools to provide access to netstat -
root@satisfactory:/config# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:7777 0.0.0.0:* LISTEN
tcp 0 0 172.17.0.3:33712 35.227.230.186:443 ESTABLISHED
tcp 0 0 172.17.0.3:47608 104.26.12.205:443 ESTABLISHED
tcp6 0 0 :::44429 :::* LISTEN
tcp6 0 0 2607:XXXX:XXXX:XXXX::44786 2620:2d:4002:1::103:80 TIME_WAIT
tcp6 0 0 2607:XXXX:XXXX:XXXX::44792 2620:2d:4002:1::103:80 TIME_WAIT
tcp6 0 0 2607:XXXX:XXXX:XXXX::44792 2620:2d:4002:1::102:80 TIME_WAIT
udp 0 0 0.0.0.0:7777 0.0.0.0:*
udp6 0 0 :::7778 :::*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 3 [ ] STREAM CONNECTED 116566441
unix 3 [ ] STREAM CONNECTED 116566442
unix 3 [ ] STREAM CONNECTED 116561616
unix 3 [ ] STREAM CONNECTED 116561617
Container attached to docker default bridge network does have IPv6 connectivity and IPv6 global transit. IE: can ping6 ipv6.google.com if inetutils-ping is added to running container.
Current docker-compose.yml
services:
satisfactory:
container_name: satisfactory
hostname: satisfactory
image: ghcr.io/wolveix/satisfactory-server:latest
restart: unless-stopped
network_mode: bridge
ports:
- 7777:7777/tcp
- 7777:7777/udp
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
environment:
- TZ=UTC
- PGID=999
- PUID=999
- MAXPLAYERS=16
- STEAMBETA=false
- SERVERIP=
# - ROOTLESS=true
deploy:
resources:
limits:
memory: 6G
reservations:
memory: 4G
Hey @goofball222! Sorry to hear that, could you try ghcr.io/wolveix/satisfactory-server:dev-301 and let me know if that addresses the issue for you, please?
Does not appear to be any change in state with that image:
root@satisfactory:/config# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:7777 0.0.0.0:* LISTEN
tcp 0 0 172.17.0.3:59010 35.227.230.186:443 ESTABLISHED
tcp 0 0 172.17.0.3:38006 185.125.190.82:80 TIME_WAIT
tcp 0 0 172.17.0.3:38062 104.26.13.205:443 ESTABLISHED
tcp6 0 0 :::35469 :::* LISTEN
tcp6 0 0 2607:XXXX:XXXX:XXXX::55068 2620:2d:4000:1::101:80 TIME_WAIT
tcp6 0 0 2607:XXXX:XXXX:XXXX::55080 2620:2d:4000:1::101:80 TIME_WAIT
udp 0 0 0.0.0.0:7777 0.0.0.0:*
udp6 0 0 :::7778 :::*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 3 [ ] STREAM CONNECTED 116911191
unix 3 [ ] STREAM CONNECTED 116910130
unix 3 [ ] STREAM CONNECTED 116911190
unix 3 [ ] STREAM CONNECTED 116910131
root@satisfactory:/config# ps auxwww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
steam 1 0.0 0.0 2892 760 ? Ss 18:05 0:00 /bin/sh /config/gamefiles/FactoryServer.sh -Port=7777 -ini:Engine:[HTTPServer.Listeners]:DefaultBindAddress=any -ini:Engine:[Core.Log]:LogNet=Error -ini:Engine:[Core.Log]:LogNetTraffic=Warning -ini:Engine:[/Script/FactoryGame.FGSaveSession]:mNumRotatingAutosaves=5 -ini:Engine:[/Script/Engine.GarbageCollectionSettings]:gc.MaxObjectsInEditor=2162688 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:LanServerMaxTickRate=30 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:NetServerMaxTickRate=30 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:ConnectionTimeout=30 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:InitialConnectTimeout=30 -ini:Engine:[ConsoleVariables]:wp.Runtime.EnableServerStreaming=1 -ini:Game:[/Script/Engine.GameSession]:ConnectionTimeout=30 -ini:Game:[/Script/Engine.GameSession]:InitialConnectTimeout=30 -ini:Game:[/Script/Engine.GameSession]:MaxPlayers=16 -ini:GameUserSettings:[/Script/Engine.GameSession]:MaxPlayers=16
steam 109 5.3 2.2 2953340 749940 ? Sl 18:06 0:25 /config/gamefiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping FactoryGame -Port=7777 -ini:Engine:[HTTPServer.Listeners]:DefaultBindAddress=any -ini:Engine:[Core.Log]:LogNet=Error -ini:Engine:[Core.Log]:LogNetTraffic=Warning -ini:Engine:[/Script/FactoryGame.FGSaveSession]:mNumRotatingAutosaves=5 -ini:Engine:[/Script/Engine.GarbageCollectionSettings]:gc.MaxObjectsInEditor=2162688 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:LanServerMaxTickRate=30 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:NetServerMaxTickRate=30 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:ConnectionTimeout=30 -ini:Engine:[/Script/OnlineSubsystemUtils.IpNetDriver]:InitialConnectTimeout=30 -ini:Engine:[ConsoleVariables]:wp.Runtime.EnableServerStreaming=1 -ini:Game:[/Script/Engine.GameSession]:ConnectionTimeout=30 -ini:Game:[/Script/Engine.GameSession]:InitialConnectTimeout=30 -ini:Game:[/Script/Engine.GameSession]:MaxPlayers=16 -ini:GameUserSettings:[/Script/Engine.GameSession]:MaxPlayers=16
root 423 1.0 0.0 7636 2940 pts/0 Ss 18:14 0:00 bash
root 431 0.0 0.0 10072 1368 pts/0 R+ 18:14 0:00 ps auxwww
docker inspect satisfactory shows:
"Labels": {
<snip>
"org.opencontainers.image.ref.name": "ubuntu",
"org.opencontainers.image.version": "22.04",
"version": "vDEV-301"
}
so it's definitely running on the updated image.
Hm, that's strange. So, we removed multihome entirely from this image, which is why SERVERIP had no effect. We did this as Coffee Stain said it was no longer needed, as it should bind to all available interfaces.
dev-301 added it back to see whether it would make a difference, though clearly not. It seems others are heaving issues with IPv6 in the Satisfactory Discord server, so I suspect it's a bug with the new server unfortunately.
This is similar to the issue I encountered before. The Satisfactory server requires a UDP port for the game port and a TCP port for the API port. Actually, the server still listens on IPv6, but only on port UDP6/7778. However, the API port is not bound to an IPv6 address. Therefore, even if you connect to the game port in IPv6 format within the game, you will still be prompted with an API connection error. For Docker containers, this issue is unlikely to cause any impact. If systemd is used to manage the server, it can listen to requests on :::7777 and forward them to 127.0.0.1:7777.
(base) ovoovo@ubuntu:~$ netstat -tunlp | grep Factory
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:7777 0.0.0.0:* LISTEN 3269100/FactoryServ
tcp6 0 0 :::36429 :::* LISTEN 3269100/FactoryServ
udp 0 0 0.0.0.0:7777 0.0.0.0:* 3269100/FactoryServ
udp6 0 0 :::7778 :::* 3269100/FactoryServ
Hey guys, was just setting up a Satisfactory server where ONLY IPv6 can be exposed via DNS (Student accomodations):
I've got it to work by adding the -multihome=:: parameter to the command (-field in TrueNAS SCALE).
The DNS contains the direct IPv6 of the docker host, with Port 7777 forwarded on TCP and UDP.
The DNS Entry contains both the local IPv4 of the host, aswell as the public IPv6 of the host.
I will be making a PR soon with the parameter brought back and setting this be default (as the wiki says that using this ensures listening on both v4 and v6 (v4 is automatically translated to [ffff::ffff:192.168.1.36] for example)
when setting it to 0.0.0.0 it ensures v4 ONLY
@Chaos02 thanks for sharing. When I spoke with CoffeeStain directly, they advised that multihome wasn't necessary since the release of 1.0. And yes, multihome respects IP norms as you've rightfully highlighted, where 0.0.0.0 is v4 and :: is dual stack.
I look forward to reviewing your PR!
I've found that not specifying Multi-Stack explicitly had issues with this particular network setup so I'll be looking forward too :)
@goofball222 if you're willing, would you mind trying v1.9.4, please?
@goofball222 if you're willing, would you mind trying
v1.9.4, please?
Running container is definitely listening on IPv6 now - https://[2001:db8::DEAD:BEEF:CAFE]:7777 responds with:
{"errorCode": "errors.com.epicgames.httpserver.route_handler_not_found", "errorMessage": ""}
I'll have to test the game connection itself over IPv6 this weekend.
Thanks so much @goofball222! Please let us know how you get on, if you get the chance :)
Hey @goofball222, have you had a chance to test this? :)
I just set up an IPv6-only hostname for a quick test and the game connects and functions as expected. Logs on the server and netstat on the client show connectivity via only IPv6 to the server. Seems like it's working as expected.