Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Fedora Linux und Online spielen
#11
Das liegt vermutlich daran, dass er vom Listserver ja die externe RouterßIP bekommt. Die ist von hinter dem Router aber nicht zugänglich. Da kann man eigentlich nichts machen (außer IPv6 verwenden). Ist eines der prinzipiellen Probleme von NAT und IPv6. Leider hat der servers.simutrans.org nur eine IP4, obwohl der Server IP6 können sollte.
Zitieren
#12
(26-05-2018, Saturday-17:26:42 )prissi schrieb: Das liegt vermutlich daran, dass er vom Listserver ja die externe RouterßIP bekommt. Die ist von hinter dem Router aber nicht zugänglich. Da kann man eigentlich nichts machen (außer IPv6 verwenden). ...

Das verstehe ich jetzt irgendwie nicht.

In den Anfangstagen ging das auch, das man übers lokale Netz mit der lokalen IP und aus dem öffentlichen Netz Kontakt zum Simutrans-Server bekommen hat. Damals hatte ich allerdings nen Windows-Rechner dafür.

Also wenn ich im internen Netz mit der internen IP zum Simutrans-Server verbinde ruft er die Daten für den Dialog auch ab.
Starte ich dann mit 'Online spielen' beginnt die Übertragung auch. Nur scheint sich der Simutrans-Server kurz nach Beginn der Übertragung der Kartendaten zu beenden. Zumindest kommt im Konsolen-Fenster der normale Prompt und der Datenabruf für den Dialog funktioniert nicht mehr.

Der Datenabruf im Dialog erfolgt über die interne IP ( also das Feld wo man die IP direkt eingeben tut ) und nicht durch Abruf über den List-Server.

Leider kann ich externen Zugriff nicht testen. Wenn es jemand testen möchte, es sind die pak64.german-Server die gelistet sind.

Die Seltsamkeiten nehmen zu.

Hab jetzt mal die Windows-Version von r8460 von der Nightly-Seite geholt.

Die meckert jetzt eine Datei als inkompatible an.
Es müsste sich um die 'way.underground_power.pak' ( angezeigt als Untergrundstrom ) handeln. Obwohl die Datei identisch ist.

Bei Linux ist alles kompatible.

Einzig das Dateidatum ist anders, warum auch immer. Allerdings ist das bei allen anderen Dateien auch der Fall. Möglich das das mit dem bauen der rpm-Pakete zusammen hängt.

links Windows, rechts Linux
[Bild: Zwischenablage02f.png]

Und statt Alias wäre Clientname oder Chatname treffender.
Zitieren
#13
Hmm, das Verbinden mit lokaler IP habe ich oft gemacht und es ging eigentlich immer. Evt. mag ja der Router nicht die externe Portweiterleitung, obwohl den das eigentlich nicht kratzen sollte.

Du kannst dich auch mit inkompatiblen Paks verbinden, indem einfach als Spielname im Ladendialog net:IP-nummer:portnummer angibst.
Zitieren
#14
Der Server bricht beim übertragen der Karte ab und ist danach nicht mehr erreichbar.

Und wenn ein und die selbe Datei mal gültig ist und mal inkompatible, da ist irgendwas im Code nicht korrekt würde ich sagen.
Oder die Compiler machen da irgendwelche Unterschiede.

Das Set ist identisch auf Windows, Xubuntu Linux in der VM und auf Fedora Linux als Server. Und alle 3 Dateien sind aus der gleichen Quelle.
Einziger Unterschied ist, das die Linux-Programmdatei 64bit von mir compiliert ist und die Windows-Version von der Nightly-Seite stammt.

Externen Zugriff kann ich wie gesagt nicht testen, da ich keinen anderen Internetzugang in der Nähe zur Verfügung hab.
Zitieren
#15
Also ich hab jetzt nochmal die Datei way.underground_power.pak vom Xubuntu-Linux aufs Windows kopiert.

Unter Linux wird sie als identisch angezeigt und unter Windows als abweichend.

Also muss es irgendwo in der Programmlogik oder bei den Compilern einen Unterschied geben zwischen 64bit Linux und dem Windows-Nightly.
Zitieren
#16
(27-05-2018, Sunday-14:44:07 )prissi schrieb: ...
Du kannst dich auch mit inkompatiblen Paks verbinden, indem einfach als Spielname im Ladendialog net:IP-nummer:portnummer angibst.

Auch damit kommt er nur bis 'Kartendaten übertragen'. Kurz drauf dann die Meldung 'Not enough bytes transferred'.

Und der Simutrans-Server ist nicht mehr ansprechbar.
Zitieren
#17
Hast du die Linux Firewall richtig gesetzt? Evt. geht "system-config-firewall" für ein grafischer Interface, oder man muss "sudo firewall-cmd --list-all" die Config anzeigen lassen. "sudo firewall-cmd --add-port=13353/tcp --permanent" sollte dann den Simutrasnport hinzufügen. Aber alles nur gegooglet, denn ich nutze Debian (oder Centos in Japan).
Zitieren
#18
Genau das war ja die ursprüngliche Frage, ob sich jemand hier mit Fedora auskennt.

Denn mit der Firewall und deren Einstellungen komm ich nicht so klar.
Zitieren
#19
(29-05-2018, Tuesday-08:16:21 )prissi schrieb: Hast du die Linux Firewall richtig gesetzt? Evt. geht "system-config-firewall" für ein grafischer Interface, oder man muss "sudo firewall-cmd --list-all" die Config anzeigen lassen. "sudo firewall-cmd --add-port=13353/tcp --permanent" sollte dann den Simutrasnport hinzufügen. Aber alles nur gegooglet, denn ich nutze Debian (oder Centos in Japan).

Wobei ich jetzt mal fragen muss, wie die Kommunikation abläuft. Also welche Ports wann benutzt werden.

Denn es funktionieren folgende Dinge

- Anmeldung beim Listserver
- Abfrage der Kartendaten per IP-Adresse und Port 13355
- die ersten beiden Sachen die angezeigt werden auf dem Balken beim Starten des Spiels gehen auch


- dann kommt Kartendaten übertragen und da bleibt der Simutrans-Server nach ca 20 - 30 Sekunden hängen und beendet die Verbindung und ist nicht mehr erreichbar

Und da die Abfrage IP:Port funktioniert im Dialog gehe ich davon aus das der Port auch durchgeleitet wird.
Zitieren
#20
Mit dem Listserver wird nur auf Port 80 kommuniziert. Erst wenn ein Server sich dort anmeldet, wird Port 13353 (oder welcher auch immer) abgefragt. Erscheint er in der Liste, geht es vom Listserver zum Server. Bekommt man die Kurzzusammenfassung, geht auch 13353 vom Client zu Server.

Mit Ubuntu hatte ich aber lange Zeit das Problem, dass bevorzugt auf IP6 gebunden wurde. Auch gab es mal Probleme, wenn übergroße Pakete gesendet wurden. Vielleicht hackt es ja dort zwischen Fedora und dem Rest.
Zitieren


Gehe zu:


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