Today, my wife and I tried to play Don't Starve Together on our LAN. We were unable to do so.
In the DST client, I opted to Browse Games. I selected the "LAN" tab. When I ran a packet capture, I noticed that, every time I clicked Refresh, a single UDP packet left my client PC. This packet was addressed to destination 255.255.255.255 (global broadcast) with source address 192.168.56.1, on UDP port 10999.
There's a few things wrong with this. Firstly, my LAN subnet is 10.0.0.0/24, so none of my computers have a route to 192.168.56.1. This would result in the reply packet getting lost. Secondly, when running a packet capture on the server, I never saw this packet arrive, despite being addresses to the global broadcast address.
I believe that Klei can fix this issue by obtaining network information from the underlying operating system. Instead of choosing a bogus IP address as the source address, Don't Starve Together should, instead, obtain the IP address and netmask from the OS. The source address should be the address received from the OS, and the broadcast address should be the subnet's local broadcast address, instead of the global broadcast. This is easily calculated from the netmask - its just bitmath.
1. Set up a LAN with two Windows computers (one client, and one server) and one Linux computer (server). Let the LAN subnet be 10.0.0.0/24. 2. Open port UDP/10999 on the Windows Server and the Linux Server. 3. Start a LAN-only DST game on the Windows server, using Don't Starve Together downloaded from Steam. 4. Search for LAN servers using the DST client on the 2nd windows computer. The search will return empty. The Windows client will broadcast one UDP packet, with source 192.168.56.1 and destination 255.255.255.255, despite the computer having an address in the 10.0.0.0/24 subnet. 5. Set up the dedicated headless Don't Starve Together server on the Linux computer. 6. Search for LAN servers using the DST client on the 2nd windows computer. The search will return empty. The Windows client will broadcast one UDP packet, with source 192.168.56.1 and destination 255.255.255.255, despite the computer having an address in the 10.0.0.0/24 subnet. The Linux computer will never recieve a UDP packet on port 10999.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now