Betreibszentrale in der LAN

[Lokführer]

Hallo, wir wollten mit einem Kollegen eine LAN machen. Nun ist folgendes Problem, das jedesmal der Multiplayer beim Verbinden wieder auf den Grundbildschirm zurück springt. Ports sind freigegeben und eine Netzwerkgruppe haben wir auch unter Windows 7. Ich bin am Ende und weiß nicht was wir noch tun können damit er sich Verbinden kann.

[TjoeTjoe]

Thomas, geht es hier um Multiplayer v2 oder Multiplayer v3?
Oder vielleicht sollte ich fragen welche SImulation du benutzt.

Und verbindet der Multiplayer "Direkt" (also Server wählen) oder benutzt er die Expert Server Option (also Benutzung mit Server Kode) ?

Erwin

[Gleissperre]

Bekannter Bug: Der Multiplayer v3 verwendet nicht die IP-Adresse, die du ihm gibst, sondern 127.0.0.1 (alias localhost). Siehe Netzwerklog. (Leider zeigt das Programm diesen Fehler nicht sinnvoll mit einer Fehlermeldung an, sondern kehrt einfach zum Ausgangsbildschirm zurück.)

Bei Verbindungen über LAN musst du keine Ports an deinem Router freigeben. Eine Netzwerkgruppe sollte auch nicht nötig sein.

[Lokführer]

Es geht um den Multiplayer 3, also haben wir keine Chance 1 Rechner über Lan zu Verbinden??

[Gleissperre]

Hallo,

nun ja, möglich ist es schon. Du kannst beispielsweise einen Tunnel verwenden: Ein Programm baut auf dem Rechner, auf dem der Client installiert ist, einen Server auf, und verbindet sich seinerseits wiederum mit dem Stellwerk auf dem anderen Rechner. Das würde dann die Fehlfunktion des Multiplayerprogramms ausgleichen.

Aber spricht etwas dagegen, bis auf weiteres einfach über 's Internet zu spielen? Du hast die Portfreigaben ja bereits eingerichtet. Wenn beide Rechner internetzugang haben, ist es egal, ob sie in einem LAN-Netzwerk sind, oder in zwei verschiedenen. Das wäre jedenfalls die einfachere Methode.

Gruß

Gleissperre

PS: Hm... Ich bin mir inzwischen gar nicht mehr so sicher, ob der Bug tatsächlich bereits bekannt ist... Ich bin zwar der Meinung, ihn irgendwo gemeldet zu haben, aber es wäre schön, wenn jemand, der Zugang zum Bug-Tracker hat, nachschauen kann, ob er auch angekommen ist...?

[TjoeTjoe]

Thomas D,

ich werde versuch einige Bilder hoch zu laden. Habe es gerade mit zwei PC's in meinem Netzwerk getestet, und es sollte funktionieren.

Man kann zwei Sachen machen:

1. Man startet am Server die Betriebszentrale (einfach mit der Taste "Aufbauen der Betriebzentrale")

Achtung: man muss einmal die Port einstellen unter "Expert Server" , zB 55388

Am Seite der Multiplayer wählt man dann "Finde Betriebszentralen" . Mann verbindet sich dann mit der Verbindung welcher mit der LAN Symbol angezeigt wird

2. Man startet am Server Simulation eine Betriebszentrale unter "Expert Server".

Dort wählt man "Finde IP Adresse". Danach im Fenster "IP Adresse wählen" unter "LAN" das eigen IP Adresse wählen und auf "Verwenden" drücken

Beobachte jetzt die "Server Kode". Der "Server Kode" kann man in Multiplayer benutzen um sich mit der Betriebszentrale zu verbinden

Im Multiplayer Programma kann man auch das IP Adresse und die Port des Server eingeben, aber der Server Kode geht schneller

Drücke auf di grüne Starte Taste. Jetzt kann der Multiplayer sich verbinden.

Im Multiplayer Programm "Verbinde mit einem Server". Im nächsten Fenster das IP Adresse und der Port des Server Simulation eingeben, oder wie gesagt der Server Kode.
Nochmals, das letzte geht schneller

Es kann sein das am Server im Firewall der benutzte Port öffnen muss

Aber wie gesagt , es funktioniert in einem LAN. Werde schnell einige Bilder im Wiki setzen.

Erwin

[TjoeTjoe]

Bilder jetzt hier in Wiki : Beispiel Verbinden Multiplayer mit Betriebszentrale über LAN

Erwin

[signalsoftRC]

Bekannter Bug: Der Multiplayer v3 verwendet nicht die IP-Adresse, die du ihm gibst, sondern 127.0.0.1 (alias localhost). Siehe Netzwerklog. (Leider zeigt das Programm diesen Fehler nicht sinnvoll mit einer Fehlermeldung an, sondern kehrt einfach zum Ausgangsbildschirm zurück.)

Bei Verbindungen über LAN musst du keine Ports an deinem Router freigeben. Eine Netzwerkgruppe sollte auch nicht nötig sein.

bin ein bissle verzweifelt hier wo was schief geht.

Verbinden ueber LAN geht immer. Das sind immer unsere lokale tests hier. Das geben wir dann haendisch ein mit der "Serverkode" (die buchstaben geschichte) und schon klappt das. Brauchst du keine routeroeffnung fuer natuerlich, bleibt ja intern im netzwerk.

also "bekannter" bug gerne mit einer repro... vielleicht kann ich schauen, wenn's da denn was gibt.

[Gleissperre]

Also ich kann das Phänomen hier zu 100% reproduzieren.

Das ist das Netzwerkprotokoll, das ein Windows-XP-PC beim Versuch sich mit IP 192.168.1.55 Port 55389 (wo eine Betriebszentrale läuft) zu verbinden, ausgibt:

Dns resolving successful, "127.0.0.1" address found.Connecting to "127.0.0.1:55389" ...

Der Verbindungsversuch scheitert.

Im folgenden habe ich auf dem eigenen Rechner (Windows 7) eine Betriebszentrale laufen. Ich versuche mich mit dem MP-Client (der sich ebenfalls auf diesem Rechner befindet, erweiterter Verbinden-Dialog) mit anderen Rechnern zu verbinden, die nicht exitstieren. Ich erwarte vom Multiplayer v3 eine Fehlermeldung oder einen sonnstigen Verbindungsabbruch. Tatsächlich Verbindet er sich jedoch mit dem eigenen Computer.

Versuch sich mit 192.168.1.14 zu verbinden. Die Adresse befindet sich im Subnetzwerk ist jedoch keinem Gerät zugeordnet.

Dns resolving successful, "192.168.1.55" address found.Connecting to "192.168.1.55:55389" ...Connection to "192.168.1.55:55389" was established.

Versuch sich mit 192.168.2.14 zu verbinden. Diese Adresse befindet sich nicht mehr im Subnetzwerk.

Dns resolving successful, "192.168.1.55" address found.Connecting to "192.168.1.55:55389" ...Connection to "192.168.1.55:55389" was established.

Versuch sich mit 192.169.1.14 zu verbinden. Diese Adresse befindet sich nicht mehr im Subnetzwerk.

Dns resolving successful, "192.169.1.14" address found.Connecting to "192.169.1.14:55389" ...

Das Programm verhält sich wie erwartet.

Versuch sich mit 191.169.1.14 zu verbinden. Die Adresse befindet sich nicht im Subnetzwerk.

Dns resolving successful, "191.168.1.14" address found.Connecting to "191.168.1.14:55389" ...

Das Programm verhält sich wie erwartet

Versuch sich mit 127.0.0.1 zu verbinden. Diese Adresse ist ein alias für den eigenen Computer.

Dns resolving successful, "192.168.1.55" address found.Connecting to "192.168.1.55:55389" ...Connection to "192.168.1.55:55389" was established.

Der Effekt ist wie erwartet. Das Log zeigt jedoch, dass er nicht die IP-Adresse verwendet hat, die ich ihm gegeben habe, sondern seine Adresse im lokalen Netzwerk. Das Programm verhält sich also auch hier falsch.

Das Verhalten scheint mit dem Log übereinzustimmen.

Windows-XP-Computer scheinen bevorzugt 127.0.0.1 zu nehmen, Windows 7 die eigenen Adresse (192.168.1.55), obwohl sich der Client mit ganz anderen Computern verbinden sollte.

[Lokführer]

Beide Rechner hatten Windows7 und waren in einer Heimnetzwerkgruppe. Die Ports waren für den Hauptpc freigegeben 55800-55900 TCP und UDP (für alle) desweiteren habe ich im Router ziwschen LAN und LAN alle Ports freigegeben. Wir haben einen anderen Sim (kein Stellwerksim) auch probiert und die Verbindung hat dort geklappt.

Danke Tjoe für die Erklärung, genauso wollten wir Verbinden und die Sim auf dem Laptop hat den fehler gemacht auf den Grundbildschirm zurück zu kehren.

@Gleisperre also wenn wir über WAN(Internet) uns Verbinden wollten passierte nix (gleiche IP). Du meinst wir sollten mal ein VPN aufbauen, so das ein Rechner eine andere IP aufweist??

[signalsoftRC]

Also, ich habe es heute abend hier probiert: Auf ein rechner kann ich 11 sims starten. Ohne probleme.

Auf 2 pc's kann ich jeweils 5 und 6 sims starten ohne probleme. auf einen dritten pc laufen 2 multiplayer zu den anderen 2...

Das einzige was ich machen musste ist beim programmstart die windowsmeldung zulassen, dass die anwendung im internet kann... (also nix mit ports freigeben. Muss nur halt alles konfliktfrei sein.

Was mache ich anders?

Witzig: heftiges gebimmelse im buero hier wegen alle ankuendigungen :-)

[Gleissperre]

Ich habe mir mal die DNS-Methoden in .Net angeschaut (eigentlich um herauszufinden, warum ihr überhaupt versucht IP-Adressen DNS-Aufzulösen ) und dabei festgestellt, dass es durchaus Methoden gibt, deren Aufruf zu dem beschriebenen Verhalten passen würde.

So liefert System.Net.Dns.GetHostEntry("192.168.1.16") bzw. ...56") zum Beispiel - neben 3 IPv6-Adressen - meine eigene IP-Adresse. Im MSDN ist da auch eine ausführliche Begründung.

Hingegen liefert System.Net.Dns.GetHostAddresses("192.168.1.16") bzw. ...56") immer die korrekte Adresse. (MSDN) Welche Methode ihr auf welche Art und Weise für die DNS-Auflösung verwendet kann ich natürlich nur Spekulieren, aber das Fehlerbild würde zunächst einmal passen. Das es bei anderen Nutzern funktioniert könnte dann möglicherweise am DNS-Verhalten des Routers liegen (was aber auch wieder nur Spekulation ist).

(Anmerkung: die 16er-Adresse ist im Netzwerk nicht zugewiesen, zu der 56er-Adresse gibt es einen Computer, der zum Zeitpunkt der Tests auch lief.)

(Und zum Log könnte es in gewisser Weise auch passen: Dann wäre die Adresse, die das Log ausspuckt nicht die, die aufgelöst werden sollte, sondern das Ergebnis der Auflösung.)

Kann natürlich auch alles andere sein... Aber wie gesagt, bei mir kann ich es immer hin zu 100 % reproduzieren, daran soll es also schon mal nicht scheitern.

[signalsoftRC]

Die Frage ist mehr, kann ich es HIER reproduzieren? Wir lösen nämlich gar keine IP Adressen auf.. Wir arbeiten nur mit direkte Verbindung und nutzen ueberhaupt keine DNS's als solches.

Wir detektieren die vorhandenen Nummern wie local host auf der eigene Maschine oder die bekannte 192.168.. reihe im Heimnetz. und verwenden die direkt. Fuer die Externe IP Adress nutzen wir einen kleinen bekannten Trick. (gleich wie 'was ist meine IP-Adresse" wie ueberall im Netz.) Alles hat absolut nichts mit DNS zu tun. Bewusst nicht.

Alle IP verbindungen sind direkt. Wenn die Beide Maschinen sich "pingen" koennen mit der IP Nummer, klappt auch die Verbindung. Wenn dann auch (nur im Externen netz!) der Router die Ports geoeffnet sind, klappt alles Problemlos.

Wenn's hapert bei den Routeroeffnungen oder, beim lokalen Netz, sehr billige und fehlerhafte/Buggy Router (ja die gibts!) verwendet wird.... geht's schief. Daran koennen wir auch nichts aendern. Koennen wir nicht mal testen hier..

[SpDrS60]

Hey Richard!

Wenns daran scheitern sollte, hab noch einen von diesen Buggy-Routern hier rumliegen, kann ich dir gerne vorbeischicken ;-)

SCNR

poldy

[RalleDU]

Die Frage ist mehr, kann ich es HIER reproduzieren? Wir lösen nämlich gar keine IP Adressen auf.. Wir arbeiten nur mit direkte Verbindung und nutzen ueberhaupt keine DNS's als solches.

Wir detektieren die vorhandenen Nummern wie local host auf der eigene Maschine oder die bekannte 192.168.. reihe im Heimnetz. und verwenden die direkt. Fuer die Externe IP Adress nutzen wir einen kleinen bekannten Trick. (gleich wie 'was ist meine IP-Adresse" wie ueberall im Netz.) Alles hat absolut nichts mit DNS zu tun. Bewusst nicht.

Alle IP verbindungen sind direkt. Wenn die Beide Maschinen sich "pingen" koennen mit der IP Nummer, klappt auch die Verbindung. Wenn dann auch (nur im Externen netz!) der Router die Ports geoeffnet sind, klappt alles Problemlos.

Wenn's hapert bei den Routeroeffnungen oder, beim lokalen Netz, sehr billige und fehlerhafte/Buggy Router (ja die gibts!) verwendet wird.... geht's schief. Daran koennen wir auch nichts aendern. Koennen wir nicht mal testen hier..

Ganz so einfach ist es leider auch nicht Richard....denke einfach nur einmal an das Problem mit den neuen IPv6 Adressen welches ich dir gemeldet habe!!

Allein wenn immer mehr Hoster hier in Deutschland auf reine IPv6 Anschlüsse umstellen werden über kurz oder lang keine Verbindungen mit der Betriebszentrale mehr möglich sein ohne das IHR da etwas tut.

Hat zwar jetzt nichts mit diesem Problem zu tun ist aber ein änlich gelagerter Fall der über kurz oder lang auf euch zukommen wird und wo du auch sagst das ihr da nichts machen könntet

[Lokführer]

Aufbau war folgender, Haupt PC 192.168.1.35 mit Win7 (Home) dort lief das Stellwerk drauf. Laptop auch Win7 mit 192.168.1.88 sollte über die Betriebszentrale verbinden (Multiplayer). Der Haupt-Rechner ist mit LAN-Kabel am Router 192.168.1.1 verbunden (Model ist Arcor WLAN 200) der Laptop über WLAN. Das Verbinden von außen in Strecke und Multiplayer ist kein Problem, funktioniert tadellos. (Ports freigeben). Beide Rechner sind im Heimlan angemeldet. Trotzdem kam es zudem Fehler, jetzt ist meine Idee aufgrund dem Post von RalleDU das IPV6 abzuschalten und nur über IPV4 zu gehen. Leider hat mein Laptop nur WinXP, was ja wieder andere Netzwerk Eigenschaften aufweist als Win7

[Gleissperre]

Wir lösen nämlich gar keine IP Adressen auf.. Wir arbeiten nur mit direkte Verbindung und nutzen ueberhaupt keine DNS's als solches.

Hm... Warum steht dann im Netzwerklog Dns resolving successful?

@Thomas D:

Kannst du mal dein Netzwerk-Log zeigen? Vielleicht hilft das ja weiter...

[Gleissperre]

Ich bekomme langsam den Eindruck, dass das Programm offenbar tatsächlich (bzw. versehentlich) versucht URLs DNS-aufzulösen, obwohl es sich um IP-Addressen handelt, die gar nicht DNS-aufgelöst werden müssen. Das würde dann auch den Eintrag im Netzwerk-Log erklären.

Von daher @Richard: Steht bei euch auch im Netzwerklog Dns resolving successful?

Was hat es denn eigentlich mit den "Buggy Routern" auf sich? Funktioniert da "nur" die Port-Weiterleitung nicht, oder verursachen die noch andere Probleme?

[Joschi2x]

Hi,

das Programm macht genau das, was im Netzwerklog drin steht. Wenn da "DNS resolving successful" steht, dann hat das Programm dies auch gemacht.

Und DNS kann und wird nicht nur zum Auflösen des Hosts in URLs benutzt. Darüber lassen sich auch Informationen wie Adressen und Namen des Hosts,

also des Ziels, erfragen. Was das Programm auch macht. Zum Beispiel zum sicherstellen das die eingegebene Adresse auch korrekt ist usw. .

Gab bisher, also bis auf dieses Foren Thema, noch keine Probleme damit. Ich denke wenn das lokale Netzwerk einigermaßen ordentlich konfiguriert ist

dürfte es keine Probleme geben. Gab es bei mir zum Beispiel noch nie.

Bezüglich IPv6 möchte ich darauf hinweisen, das DNS gerade im Bereich IPv6 immer wichtiger werden wird in Zukunft, da das eingeben dieser doch recht

langen Adressen doch sehr zeitaufwendig und mühselig ist. Ausserdem kann ich mir diese Adressen nicht merken. Desweiteren läuft IPv4 noch eine lange

Zeit weiter parallel zu IPv6 und soll sogar, soweit ich gelesen habe, dann später durch IPv6 getunnelt werden, so das IPv4 Adressen weiterhin erreichbar

sein werden für Leute die schon einen IPv6 Anschluss haben.

Gruss

[Gleissperre]

Und DNS kann und wird nicht nur zum Auflösen des Hosts in URLs benutzt. Darüber lassen sich auch Informationen wie Adressen und Namen des Hosts,

also des Ziels, erfragen. Was das Programm auch macht. Zum Beispiel zum sicherstellen das die eingegebene Adresse auch korrekt ist usw. .

Was meinst du mit "sicherstellen"? DNS-Reverse-Lookup kann zwar URLs und alternative IPs ermitteln, die der IP zugeordnet sind. Aber ein TCP-Client braucht eigentlich nur eine IP und einen Port. Den Port gebe ich seperat ein, und wenn ich eine spezielle IP eingebe, dann will ich mich auch mit dieser verbinden, und mit keiner anderen. Die Zeichenfolge auf eine korrekte Syntax zu überpfüfen geht auch mit System.Net.IPAddress.TryParse (oder mit .Parse und Ausnahmebehandlung). Dazu brauche ich kein DNS-Reverse-Lookup.

wenn das lokale Netzwerk einigermaßen ordentlich konfiguriert ist

Was ist bei dir "ordentlich"? Wie ist denn euer Netzwerk konfiguriert?

• Statische IP-Addresse?
• Statsiches DHCP?
• Dynamisches DHCP?

• Welche Router haben bei euch bereits problemlos funktioniert?

• Was sagt das Netzwerklog bei dir, wenn du versuchst dich mit einer IP zu verbinden, die zwar in deinem Subnetz ist, aber die es nie in deinem Netzwerk gab? Versucht er es dann mit der Addresse, die du ihm gegeben hast, oder tritt dann das selbe auf wie bei mir?

In meinem Netzwerk komme ich ins Internet, kann jegliche TCP-Verbindungen problemlos herstellen und verwende keine Tricks an der Router-Konfiguration, die womöglich Programme irritieren könnten. Einzig und allein Signalsoft macht Probleme.

(Das soll jetzt nicht wütend klingen, aber vielleicht hilft es ja, die Ursache etwas einzugrenzen.)

Bezüglich IPv6 möchte ich darauf hinweisen, das DNS gerade im Bereich IPv6 immer wichtiger werden wird in Zukunft, da das eingeben dieser doch recht langen Adressen doch sehr zeitaufwendig und mühselig ist.

Da gebe ich dir Recht. Aber das Programm unterstützt beim manuellen verbinden weder URLs noch IPv6. Eigentlich schade, aber selbst das könnte man immer noch System.Net.Dns.GetHostAddresses statt mit System.Net.Dns.GetHostEntry erledigen (sofern ihr das überhaupt benutzt. Aber wie gesagt das Fehlerbild würde passen.)