Satisfactory enable both IPv4+IPv6 support on servers with 2 IP addresses for these protocols

[AWL-Gaming]

Hello,

We'd like to suggest updating the Satisfactory server config to listen on both IPv4 and IPv6 addresses. The game's dedicated server now supports this natively. If you run the server's executable directly, it will listen on both IPv4 and IPv6 addresses by default. However, when using AMP, the server may only be able to bind to either IPv4 or IPv6, but not both at the same time.

Enabling this dual-stacking would allow players to connect to the server using either IPv4 or IPv6 (when the hosting server supports this) depending on their network setup, improving the overall accessibility and compatibility (including using automatic DNS resolution to A or AAAA records since the game also supports domain names).

tl;dr version: Server listens either on Or But not both through AMP

[AWL-Gaming]

Bump. Is this being worked on/planned?

[AWL-Gaming]

2nd bump. Need to know whether we should wait for an implementation or switch the hosting setup to something that supports IPv4+IPv6 natively.

[IceOfWraith]

Is it actually supported properly now? I know 1.0 had a rocky start with dual stack not working.

[AWL-Gaming]

Is it actually supported properly now? I know 1.0 had a rocky start with dual stack not working.

Yes it is fully supported. Tested to join the remote server that has a public ipv4+6 IPs, using a fully native IPv4+6 client and was able to join using both protocols.

[Greelan]

Is it just a matter of removing the MultiHome argument to cause the server to bind to both 0.0.0.0 and :: ?

[AWL-Gaming]

Is it just a matter of removing the MultiHome argument to cause the server to bind to both 0.0.0.0 and :: ?

Actually it might be! Because when you run the server's exe directly with no args (and eventually no MultiHome being present) it binds to both.

[Greelan]

That's an easy adjustment. Will do it later today

[IceOfWraith]

@Greelan Note this discussion. I'm distracted right now so unsure if this will be an issue to implement again. It was just removed a couple weeks ago due to issues.

https://discord.com/channels/266012086423912458/1015674538991812718/1283120289743507619

[Greelan]

I will test ofc

[Greelan]

The current template does use MultiHome so it appears that issue at least was resolved by the devs. Just need to check out the IPv6 binding

[IceOfWraith]

I know you'll test and do it right. Just sharing in case you weren't aware of the history. :)

[Greelan]

IPv6 on Linux still does seem cruddy. This is without MultiHome, and the port set to 7780:

tcp        0      0 0.0.0.0:7780            0.0.0.0:*               LISTEN      738971/FactoryServe 
tcp6       0      0 :::46553                :::*                    LISTEN      738971/FactoryServe 
udp        0      0 0.0.0.0:7780            0.0.0.0:*                           738971/FactoryServe 
udp6       0      0 :::7781                 :::*                                738971/FactoryServe

[Greelan]

OK, had a poke in the Satisfactory discord, and the issue is this. If the server binds to :: on Linux, that is a dual stack port - it serves both v6 and v4 traffic (like Java does). So specifically setting -MultiHome=:: on Linux will result in the server serving both v4 and v6 traffic.

However, if the MultiHome argument is omitted, then the server first binds to 0.0.0.0 on the set port (for v4 traffic). Then the server tries to bind :: on the set port too. But because :: is dual-stack on Linux, it can't bind to the set port, because the server is already listening for v4 traffic on that port. So it picks a higher port. Which explain why netstat above is showing :: listening on 7781 (the set port + 1)

The answer for the OP, then, if they are on Linux, is to change the Server IP Address in AMP to ::.

[Greelan]

Windows doesn't seem to suffer from this issue (tho oddly shows two v4 sockets on the same port):

 TCP    0.0.0.0:7777           0.0.0.0:0              LISTENING       9656
  TCP    0.0.0.0:7777           0.0.0.0:0              LISTENING       9656
  TCP    172.16.66.13:52778     172.67.74.152:443      ESTABLISHED     9656
  TCP    172.16.66.13:52782     35.227.230.186:443     ESTABLISHED     9656
  TCP    [::]:7777              [::]:0                 LISTENING       9656
  UDP    0.0.0.0:7777           *:*                                    9656
  UDP    0.0.0.0:7777           *:*                                    9656
  UDP    [::]:7777              *:*                                    9656

[Greelan]

The v6 socket on Windows also seems to be dual stack (or at least binding to v6 makes the server also listen on v4). The below is with Multhome set to :::

 TCP    0.0.0.0:7777           0.0.0.0:0              LISTENING       6052
  TCP    172.16.66.13:52977     172.67.74.152:443      ESTABLISHED     6052
  TCP    172.16.66.13:52980     35.227.230.186:443     ESTABLISHED     6052
  TCP    [::]:7777              [::]:0                 LISTENING       6052
  UDP    0.0.0.0:7777           *:*                                    6052
  UDP    [::]:7777              *:*                                    6052

[Greelan]

The solution IMO then is not to change the template

[AWL-Gaming]

OK, had a poke in the Satisfactory discord, and the issue is this. If the server binds to :: on Linux, that is a dual stack port - it serves both v6 and v4 traffic (like Java does). So specifically setting -MultiHome=:: on Linux will result in the server serving both v4 and v6 traffic.

However, if the MultiHome argument is omitted, then the server first binds to 0.0.0.0 on the set port (for v4 traffic). Then the server tries to bind :: on the set port too. But because :: is dual-stack on Linux, it can't bind to the set port, because the server is already listening for v4 traffic on that port. So it picks a higher port. Which explain why netstat above is showing :: listening on 7781 (the set port + 1)

The answer for the OP, then, if they are on Linux, is to change the Server IP Address in AMP to ::.

We're on Windows, so it looks like we're not affected by this issue (when the template eventually gets updated to remove MultiHome)? Unless there is a selective way to keep compatibility for Linux and sort it for Windows

[Greelan]

Read my later comments

[AWL-Gaming]

I did. What I was referring to is that the expected correct behavior, at least on Windows, occurs when the -MultiHome argument is removed (template update), resulting in the server listening on both IPv4 and IPv6 (compared to either v4 or v6 only).

This is with the manually updated template that is now working fine: The template can remain the same, but it will require a small additional step to manually remove that argument every time there is an update to the SF template.

[Greelan]

You might have read what I wrote, but didn't understand it. xD

If you use -MultiHome=::, then it will achieve exactly the same as your screenshot, as shown in my earlier comment.

Try it.

[IceOfWraith]

The legend strikes again.

[AWL-Gaming]

You might have read what I wrote, but didn't understand it. xD

If you use -MultiHome=::, then it will achieve exactly the same as your screenshot, as shown in my earlier comment.

Try it.

Hmm except that it does not allow IPv6 startup (-MultiHome=::) through AMP?!

[Greelan]

Lol, I know, am changing that in the PR I just raised.

But you have been doing things manually - so just try it manually in the GenericModule.kvp

[Greelan]

Or now just update your instance, since the PR has been merged