Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

myxal

Not Starving over IPv6

Recommended Posts

myxal    300

After seeing Klei silent (speechless?:p) regarding IPv6 support in DST, and with me being too cheap to rent a VPS, I was tinkering with socat and got DST to connect to a server using IPv6 as transport over the Internet. Note, this is simply to achieve direct player->server connection in situations where server isn't directly reachable over IPv4 (hello, DS-Lite). It's far from being user-friendly, so if you care about that, I suggest pestering Klei about proper support in the bug linked above. Still, setup is a lot simpler/quicker than setting up a VPN (at least for Linux/Mac users) and ping is likely faster.

As for Windows, which is used by most clients - I'm unaware of any Windows - native solution (portproxy comes so close, but doesn't support UDP). You can get socat through cygwin, or even maybe the Linux subsystem introduced in Windows 10 - I haven't tried either, and each is a fair ordeal just to get a simple UDP proxy functionality. If you know a better way, let me know!

Caveats/Overview

:wilson_goodjob:The good:

  • no per-player configuration on the server side
  • no tunnels = no MTU reduction

:wilson_cry: The bad: 

  • no discovery, players have to connect with c_connect(...) in the console
  • IPv6 connectivity needed on both sides (obviously), though v4-only clients should still be able to connect using whatever fallback DST uses (I assume Klei runs relay servers)
  • server sees all players connecting from 127.0.0.1, and client is also connecting to 127.0.0.1, so steamworks data ("Join game") will be useless

Server

Spoiler

As admin, you'll need to know:

  • ports used by each shard, and specifically which is used by the master shard - by default, these are 10998 for Master (forest) and 10999 for caves
  • your globally-unique IPv6 address (starts with 2...). Note, you'll have more of these if you have privacy extensions enabled - pick the one that isn't marked temporary.
    Linux:
    
    $ ip -6 addr show scope global
    
    macOS: See Network Preferences, or search output of ifconfig

Right. For each shard, launch socat so that it forwards udp6 to udp4:


socat -T 30  UDP6-LISTEN:<server-port>,fork,reuseaddr,bind=<ipv6_gua> UDP4-SENDTO:127.0.0.1:<server-port> &

Notes:

  • -T (inactivity timeout) allows forked processes, which are no longer used, to exit (and thus release the used ports on loopback interface). I think any value will do, as the server is always sending something to the clients. But just in case there's a short connectivity loss or server lags, you probably want to keep this above 10-15 seconds.
  • Using the same port number on the IPv6 side is not necessary, and in fact, choosing another one will allow you to bind on all addresses. This does, however complicate matters, as players must know this port when setting up their side.
  • On macOS, it seems that socat has issues reopening the UDP-LISTEN socket after the first connection. If you encounter this issue, just surround the whole command with a while loop:
    
    while true; do sleep 1; socat [...] ; done &

When inviting players, provide:

  • your global IPv6 address
  • port used by master shard (if you used different ports on v4 and v6 sides, provide both)
  • ports used by any slave shards (caves)
  • password, if any

Client

Spoiler

Players connecting via IPv6 must know:

  • host's IPv6 address
  • port used by master shard (if server used different ports on v4 and v6 sides, you'll need both)
  • port(s) or port pair(s) used by the slave shard(s)
  • password, if any

The clients must set up the same kind of forwarding, but in reverse. So for each port (or port pair) provided by the admin, run:


socat -T 15 UDP4-LISTEN:<port>,bind=127.0.0.1,fork,reuseport,reuseaddr UDP6-SENDTO:<server-ipv6>:<port> &

Notes:

Spoiler
  • -T (inactivity timeout) allows forked processes, which are no longer used, to exit (and thus release the used ports on loopback interface). I think any value will do, as the server is always sending something to the clients. But just in case there's a short connectivity loss or server lags, you probably want to keep this above 10-15 seconds.
  • Using the same port number on the IPv6 side is not necessary, and in fact, choosing another one will allow you to bind on all addresses. This does, however complicate matters, as players must know this port when setting up their side.
  • On macOS, it seems that socat has issues reopening the UDP-LISTEN socket after the first connection. If you encounter this issue, just surround the whole command with a while loop:

Then in the client app, issue in DST console (it doesn't matter which menu you're in):


c_connect("127.0.0.1", <port>, "<password>")

Notes:

  • You always connect to the master shard, even after you left the server while in caves. The slave shards are unable to authenticate you and you'll get Wrong password error.
  • You may omit the password from the console command - this will cause the regular password prompt to appear.

 

Share this post


Link to post
Share on other sites
kertinker    200

Huh, neat! Socat is amazing. There's also 6tunnel which is specialized for proxying applications that don't speak IPv6.

Puzzling that discovery doesn't work. I'd have thought discovery would send a ping over the same UDP address/port.

Share this post


Link to post
Share on other sites