What is wrong with my network settings?

[Matthew]

I am trying to set up a private Simutrans server for my own use, but I have failed. I would appreciate advice from anyone who can see what is wrong with my settings, please.

I have rented a VPS and installed both Lubuntu and Simutrans-Extended (the nightly from 2019-08-11, which I think is #8bb9199). I am able to load my pakset and savegame and play in the GUI (over a remote desktop) without any difficulties. I am also able to start the CLI version of Extended in the terminal and, judging by the terminal output, it works fine (though strangely I don't get a simu.log, so I can't post it here). But when I enter my server's IP into my client's 'Query Server' box, I only get the servers from the listing. My server's name does not appear and the 'Play Online' box remains blanked out. So I think the problem is definitely related to networking, which James says is the same for both Standard and Extended.

FWIW the client is running on Windows 7 and I have been able to connect to the Stephenson-Siemens server in the past, so I don't think it's a firewall problem there.

I have replaced personally identifiable information with XXX.

Here is the shell script that I use to start the server:

Code Select Expand

#!/bin/bash -v
pwd
/home/XXX/simutrans/simutrans-extended log 1 -debug 5 -server 13353 -lang en -load 1800s
echo Complete
read -n1 -r -p "Press any key to continue..." key

Here are the relevant settings in /home/XXX/simutrans/config/simuconf.tab (remember that there is no need for this server to be in the listings):

Code Select Expand

progdir_overrides_savegame_settings = 0
pak_overrides_savegame_settings = 0
userdir_overrides_savegame_settings = 0

pak_file_path = Pak128.Britain-Ex-235/

autosave = 1

threads = 2

listen = 116.203.XXX.XXX

server_frames_ahead = 4

additional_client_frames_behind = 0

server_frames_per_step = 8

server_frames_between_checks = 32

server_announce = 0

#server_announce_interval = 900

server_dns = 116.203.190.137

server_name = moon-stamp

#server_comments = This is a private Simutrans server - please go away!

#server_email = maintainer@your.server

#server_pakurl = http://your.domain/pakset.zip

#server_infurl = http://your.domain/server-info.html

pause_server_no_clients = 0

nickname = moon-stamp-XXX

server_save_game_on_quit = 1

chat_transparency = 75

unprotect_abandoned_player_months = 120

remove_dummy_player_months =72

#server_motd_filename =

In the pakset simuconf.tab, I have set

Code Select Expand

with_private_paks = 1
and this correctly loads my add-ons in GUI mode.

The default Simutrans port (13353) should be open on the server because sudo ufw status reports

Code Select Expand

13353/tcp                  ALLOW       Anywhere      

When the Simutrans server is running netstat -ntlp reports

Code Select Expand

tcp        0      0 116.203.XXX.XXX:13353   0.0.0.0:*               LISTEN      10332/simutrans-ext
which to a layman's eyes looks as though Simutrans is listening for connections.

The only network setting I have changed on the client is the nickname.

Can anyone spot where I have gone wrong, please?

[prissi]

First, you forget a dash "-" in front of log "-log 1". That should give you a simu.log. And better, do not use debug>3 for servers, 2 is probably even too much when it runs. Also, unless your VPN has more than one core, using threads is actually not helping and making performance words.

The only big error is the listen parameter. It is the internal interface, and an IP number there is usually not working unless you have more than one interface. It should be either :: or 0.0.0.0 or ::,0.0.0.0 depending if you have IPv6, IP4 or both. Just use the default (commented out one).

Here is the part of simuconf.tab, which I use to host my servers. Apart from the dns names, it is more or less the defaults (as it should be).

Code Select Expand


###################################network stuff##############################
#
# Synchronized networking is always a trade off between fast response and safe
# connections. A more relaxed timing will cause delay of commands but is more
# likely to compensate for clients running slightly faster than the rest.
#

# Sets the local addresses Simutrans should listen on and use for making outgoing connections
# By default it will use all local IPv4 and IPv6 addresses
# This setting has no effect if Simutrans has been compiled with the USE_IP4_ONLY flag set!
# The addresses listed will be tried in the order specified
# A DNS name may be specified, this will be resolved and Simutrans will attempt to listen
# on all of the addresses returned.
#listen = ::,0.0.0.0

# How much delay before commands are executed on the clients.
# A larger number will catch even clients running slightly ahead but cause delay.
# This is set by the server side.
#server_frames_ahead = 4

# How much extra delay in command execution on the client side, on top of server_frames_ahead.
# A larger number can compensate for larger fluctuations in communication latency to smooth out play.
# This is set by the client side.
#additional_client_frames_behind = 4

# In network mode, there will be a fixed number of screen updates before a step.
# Reasonable values should result in 2-5 steps per second.
#server_frames_per_step = 4

# The server sends after a fixed number of steps some information to the clients.
# Large values here means: reduced server communication (if that is of importance...)
# Small values should improve the timing of the clients.
#server_frames_between_checks = 24

# Automatically announce server on the central server directory (http://servers.simutrans.org/)
# 0 (default) = off, 1 = on
server_announce = 1

# Value is number of seconds between server announcements, default is 900 (15 minutes)
# Minimum value is 60 (1 minute), for accurate listing it is recommended not to increase
# this value to greater than 3600 (1 hour)
# To disable announcements set server_announce to 0
server_announce_interval = 900

# Fully Qualified Domain Name (FQDN) or IP address of your server (IPv6 or IPv4)
server_altdns = 2a03:4000:8:1fe::1

# alternative server name (an or IP6) Use only if server_dns is set!
server_dns = v22017044590048878.supersrv.de

# Port address (usually set via command line)
#server_port = 13353

# Name of server in server listing
server_name = "Little Simutrans World"

# Additional information about your server (for display on the list server)
#server_comments = Comments about my server

# Email address of server maintainer (for display on the list server)
#server_email = maintainer@your.server

# Pakset download URL (for display on the list server)
#server_pakurl = http://your.domain/pakset.zip

# Server info URL (for display on the list server)
#server_infurl = http://your.domain/server-info.html

# Pause server when no clients are connected
pause_server_no_clients = 1

# Server saves savegame when being killed (default=0 off)
server_save_game_on_quit = 0



Second, from you home computer, try to load the game "net:116.203.190.137". If it loads, then the announce settings are wrong, but your server is running fine.

Finally, since Simutrans sets up UPnP tunnels automaticallz, zou could host a private system at home easily. No need to rent something.

[ACarlotti]

Also, unless your VPN has more than one core, using threads is actually not helping and making performance words.

This isn't necessarily true for Extended, since Extended currently requires that the same number of threads is used on both the server and the clients. So if some of the clients would benefit from threading, then it is probably best to enable it on the server.

[DrSuperGood]

Also, unless your VPN has more than one core, using threads is actually not helping and making performance words.

VPNs have no processor and cannot execute code. They are Virtual Private Networks. VPSs do have a processor. They are Virtual Private Servers.

I have rented a VPS and installed both Lubuntu and Simutrans-Extended (the nightly from 2019-08-11, which I think is #8bb9199).

Apparently the nightlies from around that time had issues with multiplayer working. No one could connect to servers using them. Try a newer nightly build in case it has been fixed.

[Matthew]

Thank you to everyone who kindly replied; I learned something from all of your posts.

I have discovered that the cause of my failure to connect was a complete beginner's error: pakset mismatch.  I assumed that Extended package for Debian would automatically be using the latest Nightly pakset, but this turned out not to be the case.

First, you forget a dash "-" in front of log "-log 1". That should give you a simu.log.

Another beginner's error.  Oops! Thank you.

It also turned out that when a log was generated, it was called "simu-server13353.log", so my searches for "simu.log" did not find it.

And better, do not use debug>3 for servers, 2 is probably even too much when it runs.

I have changed it, thank you.

Also, unless your VPN has more than one core, using threads is actually not helping and making performance words.

My current VPS has two virtual cores, on the assumption that Simutrans will max out one while the other runs the system.

The only big error is the listen parameter. It is the internal interface, and an IP number there is usually not working unless you have more than one interface. It should be either :: or 0.0.0.0 or ::,0.0.0.0 depending if you have IPv6, IP4 or both. Just use the default (commented out one).

Hmm. Not sure what's happening here.

Here is the part of simuconf.tab, which I use to host my servers. Apart from the dns names, it is more or less the defaults (as it should be).

<snip>

Thank you for providing your settings. It's interesting that you've left the frame settings commented out: I will try to play about with these as the lag is quite bad sometimes.

Second, from you home computer, try to load the game "net:116.203.190.137". If it loads, then the announce settings are wrong, but your server is running fine.

Do you mean at the command line or in the 'Play Online' dialog box, please?

Finally, since Simutrans sets up UPnP tunnels automaticallz, zou could host a private system at home easily. No need to rent something.

This is a helpful thought, but I am experimenting with the VPS because leaving my laptop on overnight was in danger of causing family arguments over the alleged fire risk. €7/month may be a price worth paying for peace & quiet. And I'm enjoying relearning Linux.

This isn't necessarily true for Extended, since Extended currently requires that the same number of threads is used on both the server and the clients. So if some of the clients would benefit from threading, then it is probably best to enable it on the server.

Really?! If identical thread settings are a requirement, then this should be stated in simuconf.tab! This might explain another problem I've had.

[ACarlotti]

Really?! If identical thread settings are a requirement, then this should be stated in simuconf.tab! This might explain another problem I've had.

The server sends the thread count to the client, so that the number of threads used is synchronised across all systems. The only potential for incompatibility here is if you compile a version with MULTI_THREAD set (or not set) to disable threading, in which case you won't be able to connect to other versions that were built with threading.

[Vladki]

server_announce = 0
Change that to 1 to be listed