Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Problem mit Simutrans server public announcement
#1
Hallo Leute,

ich wollte einen kleinen Simutrans Test server aufsetzen und ihn auch in die Serverliste setzen.
Das Ganze soll auf einem Raspberrypi laufen. Oder vilmehr will ich sehen, was auf dem Raspberrypi möglich ist, Simutrans server technisch. Habe dazu nämlich nicht viele Infos gefunden.

Zuerst mein Setup:
Raspberrypi B mit raspbian, aktuelle version
Simutrans 120 headless aus dem sourcecode kompiliert

Das Ganze hängt (leider) hinter zwei Fritzboxen:
In der 1. Fritzbox, die mit VDSL ans Internet angebunden ist, ist die zweite Fritzbox als exposed host eingetragen. Es sollten also per se alle ports weitergeleitet werden.
Bei der 2. Fritbox, die dahinter hängt, sind die entsprechenden ports für TCP und UDP explizit freigegeben.

Das Ganze funktioniert auch astrein, solange ich nicht den Hostname (von no-ip.com) angebe. Sobald ich das tue, versucht simutrans beim Serverstart den Hostname aufzulösen und checkt, ob der entsprechende Port offen ist (vermute ich mal). Da das aber nicht der Fall ist, bindet er nicht an den Port, was dazu führt, dass der Port nie geöffnet ist (wird).

Wenn ich keine explizite IP Adresse angebe, startet der server und der Port ist offen. Allerdings geht ja kein announce, wenn der hostname nicht eingetragen ist.

Hier die Fehlermeldung von Simutrans:

Code:
Message: socket_list_t::add_server:     add server socket[5]
Message: network_init_server(): Preparing to bind address: "my_hostname.no-ip.org"
Message: network_init_server(): Attempting to bind listening sockets for: "my_hostname.no-ip.org"

Message: network_init_server(): Potential bind address: 93.xxx.xxx.xxx
FATAL ERROR: network_init_server() - Unable to bind socket to IP address: "93.xxx.xxx.xxx"
Aborting program execution ...

Hat jemand eine Idee, was ich falsch mache, bzw. Wie ich das Problem umgehen kann?

Liebe Grüße,
fluorid
Zitieren
#2
Also zuerst müsstest du port 13353 weiterleiten, über den läuft nämlich die interne Kommunikation (Kannst natürlich auch einen beliebigen anderen port angeben). Der Serverlist-Server versucht von deinem Server einen Spielstatus zu bekommen. Klappt das, dann wird er in die Liste eingetragen. TCP wird nur für die Kommunikation im Spiel verwendet, wenn sichergestellt werden soll, das Spielstände und Kommandos korrekt und in der richtigen Reihenfolge übertragen werden.
Zitieren
#3
Hallo,

danke für deine Antwort, prissi. Das ist mir soweit alles klar. Ich habe anstatt des Standardport Port 13421 verwendet, aber das sollte keinen Unterschied machen.

Mein Setup habe ich ja im 1. Beitrag schon erläutert. Um es nochmal deutlicher zu machen:

Wenn der Server gestartet ist ohne an die no_ip url gebunden zu sein, geht alles und der Port ist offen. Wenn ich den server versuche zu starten und die no-ip url ist eingetragen komme ich gar nicht zu dem Punkt, wo der sevrer startet. Ich vermute der server startet nicht, weil der Port nicht offen ist. Aber der Port wird von der Fritzbox erst aufgemacht, wenn sich ein Programm dran gebunden hat. Kann das sein? Das wäre ja dann so eine Art Henne - Ei Problem...

Portscan auf no-ip url mit nmap ohne gestarteten server:
Code:
ich@mypc:~$ nmap mydyndns.no-ip.org -p 13421

Starting Nmap 6.47 ( http://nmap.org ) at 2016-10-19 20:19 CEST
Nmap scan report for mydyndns.no-ip.org (93.219.xxx.xxx)
Host is up (0.0040s latency).
rDNS record for 93.219.xxx.xxx: xxxyyyzzz.dip0.t-ipconnect.de
PORT      STATE  SERVICE
13421/tcp closed unknown

Hier das Ganze nachdem ich den server gestartet habe, ohne die dyndns url explizit anzugeben:

Code:
ich@mypc:~$ nmap mydyndns.no-ip.org -p 13421

Starting Nmap 6.47 ( http://nmap.org ) at 2016-10-19 20:22 CEST
Nmap scan report for mydyndns.no-ip.org (93.219.xxx.xxx)
Host is up (0.0041s latency).
rDNS record for 93.219.xxx.xxx: xxxyyyzzz.dip0.t-ipconnect.de
PORT      STATE SERVICE
13421/tcp open  unknown

Any ideas?

Lg, fluorid
Zitieren
#4
ich bin jetzt nicht der Server-Experte, aber:

Nur die 1. Fritzbox kann die IP via no-ip auflösen (bzw. no-ip kann nur die 1.Fritzbox "sehen" und nicht, was alles noch dahinter kommt --> deine 1. fritzbox muss also für no-ip eingerichtet sein und nur hier kann die fritzbox "ihre" aktuelle ip melden und no-ip deinen dns.no-ip-namen auflösen)
die 2. fritzbox kann das nicht, weil ihr diese ip nicht bekannt ist, daher kannst du von hier aus nur über die portfreigabe der 1. Fritzbox nach "draußen" kommunizieren
Fatal ist, wenn sich das Licht am Ende des Tunnels als entgegenkommender ICE erweist.
Zitieren
#5
Hallo,

danke für Deine Antwort, papa69.

Also ich bin jetzt auch nicht unbedingt der Serverexperte aber das ist quatsch.

Die Fritzbox muss ja nichts auflösen.

Der Client, also die Person die mitspielen will, bzw. der Simutrans announcement server muss die no-ip Adresse auflösen können, bzw. die richtige IP dazu sehen können. Das funktioniert auch einwandfrei.
An der 2. Fritzbox ist Port 13421 freigegeben. Da die 2. Fritzbox als exposed host in der 1. eingetragen ist, schickt die 1. Box alles was reinkommt und nicht zu einer bestehenden Verbindung gehört auf die 2. Box weiter. Diese hat eine Portfreigabe auf 13421 (den Port, den ich verwenden will). Somit kommt auch alles am RaspberryPI an, wie es soll. Ich kann mich auch via dyndns auf den Server verbinden. Das setup scheint OK zu sein.

Was nicht geht ist der server announce.

Was ich inzwischen kapiert habe: Klar kann der RaspberryPI (mein simutrans server) nicht an die externe ip binden. Er hat schließlich kein interface, dem diese ip Adresse zugewiesen ist.
Aber was muss ich nun wo eintragen, damit das announce funktioniert? Bisher sieht der Netzwerkabschnitt meiner simuconf.tab so aus:

Code:
###################################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 = 192.168.xxx.xxx  <- Hier im Moment lokale IP Adresse eingetragen. Auch mit 0.0.0.0 probiert. Kein Unterschied

# 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.
# This is set by the client side.
#additional_client_frames_behind = 0

# 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 = 128

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

# Interval of server announcement (if enabled)
# 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 = 300

# Fully Qualified Domain Name (FQDN) or IP address of your server (IPv6 or IPv4)
server_dns = mydyndns.no-ip.org

# Name of server in server listing
server_name = fluorids server

# Additional information about your server (for display on the list server)
server_comments = This is a server on a raspberryPI. I'm trying out how stable it is. Feel free to play a bit. No guarantee for being up 24/7$

# Email address of server maintainer (for display on the list server)
server_email = mymail@my.mail
# 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    <--- Brauche ich das vielleicht?

# Pause server when no clients are connected
#pause_server_no_clients = 0

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

# Nickname when joining network games
#nickname = John Doe

# Chat window transparency (0=off, 25, 50 75 are possible)
chat_transparency = 75

# Here you can add a message about your server (It will read this file on each joining anew)
server_motd_filename =/home/pi/simutrans/server_message

Passt die config so?

Lg,
fluorid
Zitieren
#6
Kommentier "listen" aus; für das gibt es eigentlich keine vernüftige Anwendung, wenn du nicht gerade mehr als einen Netzwerkschnittstelle hast.

Setz mal statt dem symbolischen Namen die richtige IP händisch (also server_dns = 149.55.49.1 oder was deine externe IP ist), dann sollte der Listserver deine IP sehen. Wenn es dann keine Antwort kommt, dann musst du dich mal mit der Kommunikation zwischen den Fritzboxen befassen.

Ich hatte zwar nie 'ne Fritzbox, aber bei fast alle Routern, die ich je gesehen hatte, konnte man auch portweise weiterleiten. Und mit einer einfachen Portweiterleitung von 13353 (bzw. bei dir eben 13421) ist es schon erledigt. Also Testvorschlag: Port 13421 weiterleiten, listen auskommentieren, und nochmal versuchen.

Alle IP und sonstige Verbindungen baut der Server auf, und die muss nur der Router nach draußen lassen. EIne DMZ ist völlig überkandidelt und wird den PI eher überlasten, bei dem Müll der typischerweise aus dem Netzt schwappt.
Zitieren
#7
Hallo,

danke für Deine Antwort, prissi.

Ich habe "listen" auskommentiert und es mit der IP Adresse probiert. Funktioniert. Mit der dyndns url funktioniert es nicht.

Die 2. Fritzbox leitet ausschließlich port 13421 an den raspberryPI weiter. Der bekommt also keinen Müll aus dem Internet ab.


Der dyndns name lässt sich prima auflösen und wenn man ihn manuell einträgt und den server abfragt kann man sich ohne Probleme verbinden. Das ist schon seltsam...

Noch irgendwelche Ideen?

Lg, Fluorid
Zitieren
#8
Da es mit IP Adresse geht und mit dynamischen Namen nicht, hat sich auch bei einem kurzen Test mit NoIP herausgestellt. Keiner der aktiven Server hat einen Symbolischen Names. Irgendwas scheint da am Server zu haken. Leider ist das Node-Skript nicht von mir und ich habe nur rudimentäre Kentnisse davon.

EDIT: Symbolische IP-Adressen gehen wieder ...

EDIT2: Und schon sind doppelt so viele Server da!
Zitieren
#9
Hey!

Yayy! Das ist ganz großartig. Jetzt geht es perfekt. Habe schon ernsthaft an mir gezweifelt :-). Rein aus Interesse: Wo lag das Problem?

Lg, fluorid
Zitieren
#10
Die neuere Version von node.js kopiert den Präfix ::ffff: vor jede IP4 Adresse und vor jeden DNS-Namen. Damit scheitert die Abfrage, ob die Adresse eine gültige DNS-Adresse ist, den das Nachschlagen geht nicht. Daher war in der IP4-Nummerabfrage schon ein Test auf "::ffff:" als Präfix drinnen, aber nicht bei DNS-Name. Runterkopiert und es ging; hat mich aber auch drei Stunden suchen gekostet. Bei Interesse mal auf simulist auf github anschauen.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste