Firsty Posted February 10, 2013 Posted February 10, 2013 (edited) Hallo, mir ist es heute das erste Mal gelungen mit jemandem über Streckenverbindung/Betriebszentrale 2 Stellwerke zu betreiben. Supervisor.exe/Betriebszentrale-Ansicht meldete aber einen Fehler. : [11:55:46] Fehler: Anwender '93.217.125.159' (KB) hat keine Simulationsinformation gesendet. Der Anwender hat Netzwerkprobleme mit seinem Computer und/oder Router[... viele ähnliche Meldungen dazwischen][12:09:27] Fehler: Anwender '93.217.125.159' (KB) hat keine Simulationsinformation gesendet. Der Anwender hat Netzwerkprobleme mit seinem Computer und/oder Router In der Betriebszentralen-Ansicht konnte ich die kommenden Züge aus KBBG sehen. Mein Bf. KB war aber grau. Leider kann man hier keine Dateien anhängen. Ich habe Screenshots von der Betriebszentralen-Ansicht und der Portfreischaltungen gemacht, damit der Fehler deutlich wird und ein eventueller Fehler auf meiner Seite besser erkannt wird. Für Hilfe bin ich dankbar. Viele Grüße Firsty Edited February 10, 2013 by Signalsoft Support Canada too much text
signalsoftRC Posted February 10, 2013 Posted February 10, 2013 Routerprobleme sind sehr individuelle Probleme.... Da es tausende Modelle und Formen von Routern gibt. Lesen der Anleitung hilft sehr. Was wir auch mehr und mehr entdecken: Es gibt sehr buggy Router die einfach nicht machen, dass wofür die erstellt sind. Mit 11 Simulationen zu verknüpfen ist es sehr wichtig die Ports zu verwalten. Hier ist ein Plan: http://www.railsignalling.org/signalwiki/index.php/Simulation_Network_In_Detail#Port_mapping_plan
Camore173 Posted October 3, 2015 Posted October 3, 2015 Hallo zusammen, der Thread ist zwar schon älter aber ich würde Ihn gerne nochmal aufgreifen. Ich bekomme die selbe Fehlermeldung wie oben um 1. Post beschrieben. Habe auch alles so eingestellt wie im Wiki angegeben und kann mich auch mit anderen Verbinden. Im Supervisor bleibt mein Stellwerk allerdings immer grau. Auch wenn ich selbst eine Streckenverknüpfung starte und dann im Supervisor diese ansehen möchte bleibt mein Stellwerk grau und ich bekomme eingangs erwähnte Meldung, obwohl die Anzeige unten rechts grün ist. Bedeutet das, dass sich niemand mit mir Verbinden kann wenn ich eine Streckenverknüpfung starte? Schon mal Danke für die Hilfe Gruß
DevonFrosch Posted October 4, 2015 Posted October 4, 2015 Na dann erzähl mal: - Um welches Stellwerk geht es? - Welche Ports (3 Stück) hast du eingetragen? Hast du sie alle getestet? - Lässt die Firewall das Programm durch? - Sind alle Ports im Router auf deinen Rechner weitergeleitet (= Portfreigabe)? - Was für ein Routermodell hast du? - Hat der eine Art DDoS- oder Flooding-Schutz, den man abstellen kann? Gruß, DevonFrosch
Camore173 Posted October 4, 2015 Posted October 4, 2015 Es geht um Bonn Hbf. Es sind die Ports 56390 TCP und 57390 UDP im Stellwerk eingetragen. Und die Tests sind auch erfolgreich für beide. Im Supervisor ist 57999 eingetragen und dieser Test funktioniert ebenfalls. In der Firewall habe ich beide Programme auch freigeben. Router ist ein Speedport W724 V wo auch o.g. Ports auf meinen Rechner weitergeleitet werden. Wie gesagt: Ich kann mich Problemlos mit anderen Verbinden wenn jemand eine Streckenverknüpfung gestartet hat, und es funktioniert auch alles wie es soll. Nur im Supervisor bleibt mein Stellwerksbereich immer grau und es scheint so als würde mein Stellwerk keine Daten senden. Evtl. habe ich auch nur einen Denkfehler und es ist nicht weiter dramatisch das dass so ist. Grüße
DevonFrosch Posted October 4, 2015 Posted October 4, 2015 Hallo, Bedeutet das, dass sich niemand mit mir Verbinden kann wenn ich eine Streckenverknüpfung starte? Auf die Frage hatte ich noch gar nicht geantwortet: Ja, weil der Supervisor nicht sieht, dass das Stellwerk besetzt ist, und deswegen nur anbietet, in dein Stellwerk zu gehen, nicht aber in dein (anderes) Nachbarstellwerk. Es geht um Bonn Hbf. Es sind die Ports 56390 TCP und 57390 UDP im Stellwerk eingetragen. Und die Tests sind auch erfolgreich für beide. Im Supervisor ist 57999 eingetragen und dieser Test funktioniert ebenfalls. In der Firewall habe ich beide Programme auch freigeben. Router ist ein Speedport W724 V wo auch o.g. Ports auf meinen Rechner weitergeleitet werden. Wie gesagt: Ich kann mich Problemlos mit anderen Verbinden wenn jemand eine Streckenverknüpfung gestartet hat, und es funktioniert auch alles wie es soll. Nur im Supervisor bleibt mein Stellwerksbereich immer grau und es scheint so als würde mein Stellwerk keine Daten senden. Evtl. habe ich auch nur einen Denkfehler und es ist nicht weiter dramatisch das dass so ist. Grüße Schau doch mal im Router-Log nach, ob dort irgendwelche Fehlermeldungen auftauchen. Ich kenne einen anderen Benutzer, der das Problem bei einem Vodafone-Router hatte - der Router kam mit den vielen Paketen, die der Sim an den Supervisor schickt, nicht klar (der Flooding-Schutz sprach an). Er hat eine Option, um den zu deaktivieren. Gruß, DevonFrosch PS: Die Telekom ist allerdings nicht unbedingt für fehlerfreie Router bekannt, bei meiner Suche gerade kamen Foren-Threads zu SYN-Flood-Meldungen, die von deren eigenen Media Center verursacht wurden...
Camore173 Posted October 4, 2015 Posted October 4, 2015 Guten Abend, danke erstmal für die ganzen Tipps! Ich habe mir mal den Router Log angesehen, das steht aber nichts auffälliges drin. Mir sind jetzt auch die Ideen ausgegangen und werde die Stellwerke erstmal ohne Streckenverknüpfung weitersimmen. Macht ja auch genug Spaß! Danke nochmalGruß
Gleissperre Posted October 4, 2015 Posted October 4, 2015 Hallo, ich schreibe dazu mal einfach einen größeren Roman. Die Sache ist nämlich die: Es gibt 3 mögliche Ursachen: 1. Das Protokoll des Supervisors ist ein bisschen ungünstig gelöst. Zum einen ist es ein genereller Designfehler, UDP zu verwenden und dann jeweils nur die aktuellen Änderungen zu übertragen. Entweder UDP und in einem langsamen Rhythmus immer zyklisch kleine Teile des Stelltisches senden, oder gleich TCP verwenden. Die aktuelle Implementierung führt hingegen dazu, dass regelmäßig "auf dem Weg" Daten verloren gehen. Ein Problem scheint bei manchen Stellwerken zu sein, dass das allererste Paket, das angibt, wie das Stellwerk beim starten aussieht, zu groß ist, und daher gerne etwas davon verloren geht. Während des Betriebes des Stellwerks wird bei jeder Änderung ein Paket gesendet. UDP ist so designt, dass Pakete auch mal verloren gehen können. Das passiert auch. Wäre aber nicht schlimm, weil der Supervisor ist ja nur zum Beobachten dar. Dazu müsste man allerdings die Daten nicht nur bei einem Anlass, sondern auch ohne Anlass, also in regelmäßigen Zeitabständen automatisch senden. Da das nicht gemacht wird, kann ich an meinem PC regelmäßig Fehler in der Darstellung erkennen, die nicht von alleine verschwinden. Im Extremfall kann das dann dazu führen, dass überhaupt keine aktuellen Daten am Supervisor ankommen. Dann markiert Signalsoft das Stellwerk als "tot" und man könnte sich nicht verbinden. Aber das passiert eher selten. Üblich ist eine völlig unbrauchbare Darstellung im Supervisor, aber genug Daten verbleibend, um sich noch als Nachbar verbinden zu können. 2. Das Problem mit den Routern. Ich erkläre es mal an einem historischen Beispiel: Es gab (gibt) ja Firmen, die ein internes Telefonnetz mit eigner Telefonanlage hatten (haben). Dann hat man z.B. unter #123 Herrn Mayer von der Abteilung XY erreicht. Wenn dies eine kleinere Firma war, könnte es aber auch sein, dass die Firma nach außen nur eine einzige Telefonnummer hatte (z.B. 01234 5678), wo es dann eben nur bei der Sekretärin geklingelt hat. Man kann sich Signalsoft als ein Mitarbeiter in dieser Firma vorstellen, der genau das macht: Um Herrn Mayer zu erreichen, wählt er nicht die #123 sondern die 01234 5678 geht damit ins Ortsnetz (Amtsholung) (bzw. geht damit ins Internet) nur um sofort wieder umzukehren, landet bei der Sekretärin, die ihn dann an die #123 weiterverbindet/weiterleitet. Er erreicht das Ziel über einen großen Umweg (der früher sogar Geld kostete - Anrufe waren ja früher nicht als "Flatrate" zu haben). Normalerweise kann Signalsoft Herr Mayer natürlich trotz dieses Umweges erreichen. Aber wenn die Sekretärin gerade mit jemand anders telefoniert hat, war ihre Leitung besetzt. Wenn die Router so arbeiten, wie sie arbeiten sollten, haben sie "zwei Leitungen" und es funktioniert. Aber solche Umwege wie eben beschrieben macht eben fast keiner - außer Signalsoft. Deswegen wird von den Router-Herstellen auch häufig nicht vernünftig getestet, ob diese Umwege auch funktionieren. Und dann entstehen eben Bugs. Das bedeutet, dass die Daten von der Simulation Bonn Hbf ins Internet gehen, dort wieder umkehren und sich auf den Weg zurück zu deinem Computer machen, und dort vom Supervisor wieder empfangen werden. Wenn die Daten dann beim Versuch, wieder umzukehren, aus der 180°-Kurve fliegen, dann zeigt der Supervisor an, dass nichts angekommen ist. Wenn du allerdings nicht mit dir selbst telefonierst, sondern mit einem Freund/Freundin, so seit ihr in verschiedenen Häusern und habt damit verschiedene IP-Adressen. Deshalb ist die Kurve keine 180°-Kurve mehr (sondern höchstens noch 90°) und die Daten fliegen auch nicht aus der Kurve. Das führt dann zu der seltsamen Situation, dass du denkst, deine Streckenverbindung wäre NICHT erreichbar, in der Praxis sie aber durchaus für andere Leute erreichbar ist! Das heißt, in diesem Falle kann sich dann tatsächlich auch jemand mit dir verbinden! 3. Dann gibt es noch die Option, die DevonFrosch erklärt hat: Dein Router hat zahlreiche Schutzmechanismen um die Gefahr von Angriffen aus dem Internet zu verringern. Es kann sein, dass irgendeiner dieser Mechanismen Greift - sei es weil irgendein 3. Programm einen Fehlalarm auslöst oder der Router allgemein zu restriktiv konfiguriert ist. In diesem Fall bist du dann tatsächlich nicht erreichbar. Diese 3 Probleme erheben natürlich keinen Anspruch auf Vollständigkeit, aber Häufig sind es eben diese Punkte: Schleche Verbindung (trotzdem erreichbar), Verbindung zu allen außer dir selber (trotzdem erreichbar), und tatsächlicher Fehler (nicht erreichbar). Schlusswort: Solange du nicht den Zeitraffer benötigst, kannst du den Supervisor ruhig anlassen. Es gibt 2 von 3 Fehlerursachen, bei denen du trotzdem erreichbar bist. Am besten du gibt mal Bescheid, wann du online bist, dann kann mal einer von uns hier im Forum nachprüfen, ob du tatsächlich nicht erreichbar bist, oder ob es sich nur einmal mehr um einen Fehlalarm handelt.
Camore173 Posted October 5, 2015 Posted October 5, 2015 Hallo Gleissperre, danke erstmal für deine Ausführliche Erklärung. Dadurch verstehe auch ich als "Standard" PC Bediener einige zusammenhänge besser. Soeben habe ich auch folgende Fehlermeldung in meinem Router entdecken können: DNSv6-Fehler: Der angegebene Domainname kann nicht von 2003:180:2:9000:0:1:0:53 aufgelöst werden. Fehler: DNSv6 Address Unreachable. (P008) Vll. trägt das ja zu Problembehebung bei oder hat was damit zu tun. Danke nochmal für die Geduld mir bei meinem Problem zu helfen! Grüße
JulianG Posted October 6, 2015 Posted October 6, 2015 Ja, da haben wir den Salat, da beißt sich dein IPv6 mit dem IPv4-Standard, den Signalsoft benötigt. Lies mal hier: http://www.signalsoft.info/forum/index.php?showtopic=2049
RalleDU Posted October 6, 2015 Posted October 6, 2015 Hallo aus eigener Erfahrung (ehemals IpV4 und Telekom mit Speedport Router jetzt Unitymedia mit IpV6 und DualstackLite) kann ich sagen, dass hie wahrscheinlich sogar zwei Probleme zusammen kommen. Zum einen ist der Speedport dafür bekannt Firmwareseitig das "NAT Loop" nicht zu unterstützen. Das führt schon bei IpV4 dazu das zB Stellwerke im Supervisor kurz auftauchen und wieder verschwinden (eine Verbindung über "Servercode" ist aber jederzeit und stabil möglich. Beim IpV6 Problem (oben genannter Link) ist es schlicht das Problem das Signalsoft keine Anpassung macht. Ich habe Richard vor langer zeit darauf hingewiesen das dieses Problem in Europa mehr und mehr mit Neuverträgen auftauchen wird aber er sieht hier leider keine Handlungsbedarf (Microsoft und andere haben hier natürlich schon lange umgestellt). Im Moment bleibt bei IpV6 und DualstackLite nur die eine zuverlässige Lösung, sich einen sogenannten Tunnel (ich zb habe ihn über Portunity) anzumieten und diesen in OpenVPN einzubinden. Dies ist leider mit zusätzlichen kosten (in meinem Fall ca 50 Euro pro Jahr) verbunden. Hat man OpenVPN eingerichtet startet man das Programm vor dem spielen und alles läuft wunderbar Gruß Ralf
Gleissperre Posted October 6, 2015 Posted October 6, 2015 Also ich lese aus der Fehlermeldung nicht heraus, dass DS-Lite aktiv wäre. @Camore: Schau mal, ob du in deinem Router den Text "DS-Lite" findest. Wenn ja, bist du von dem von Julian verlinkten Problem betroffen. Aber ich gehe erst mal nicht davon aus. Solltest du kein DS-Lite besitzten, kann womöglich ein neuer Router helfen. FritzBoxen können normalerweise auch problemlos mit allen Anschlussarten umgehen, selbst wenn die Telekom ein eigenes Produkt liefert. @RalleDU: Was ich nicht verstehe: Es ist eigentlich (zumindest bei meinen Programmen) nur eine Zeile Code, die man für IPv6-Support anpassen müsste: In den Konstruktor der System.Net.Sockets.TcpClient-Klasse den IPEndPoint.AddressFamily-Member zu übergeben. Damit ist zumindest der Client dann IPv6-Fähig. Und beim Server geht das völlig analog. Und ich sehe keinen Grund, wieso Richard nicht einfach IPv6 unterstützt...
RalleDU Posted October 6, 2015 Posted October 6, 2015 ..diese frage musst du nicht mir sondern Richard stellen. Vor ein Paar jahren habe ich auf das kommende Problem hingewiesen und es ist bis heute nichts geschehen. Ich kann nicht beurteilen was hierfür geändert / neu programmiert und getestet werden muss und welchen aufwand das bedeutet.
DevonFrosch Posted October 6, 2015 Posted October 6, 2015 Moin, na ja, etwas Aufwand dürfte darin stecken, dass die Clients ihre IP-Adressen als toll Buchstaben-Servercodes durch die Gegend schicken. Diese Codes müsste man erheblich länger machen, um IPv6-Adressen darin unterzubekommen. Deswegen wird das vermutlich etwas Testaufwand, um zu schauen, ob danach wirklich alles wie bisher funktioniert. Leider fällt sowas unter "Refactoring" und ist damit bei Entwicklern und Produktmanagern (insb. in Unternehmen) generell gaaaaaanz unten angesiedelt... Bringt ja kein Geld, nur weniger Gemecker, das kann man schlecht fühlen/messen. Gruß, DevonFrosch
Camore173 Posted October 7, 2015 Posted October 7, 2015 Hallo zusammen, den von Gleissperre angegebenen Text "DS-Lite" konnte ich bei mir nirgends entdecken. Ich werde mich jetzt erstmal einfach damit abfinden das es bei mir nicht funktioniert; aus welchen Gründen auch immer. Vll. wird es zukünftig ja mal angepasst das es einfacher ist diese Funktion zu nutzen. Danke auf jeden Fall an alle für die Ratschläge Grüße Camore
JulianG Posted October 7, 2015 Posted October 7, 2015 Also ich lese aus der Fehlermeldung nicht heraus, dass DS-Lite aktiv wäre. Wenn ich die Fehlermeldung lese: DNSv6-Fehler: Der angegebene Domainname kann nicht von 2003:180:2:9000:0:1:0:53 aufgelöst werden. Fehler: DNSv6 Address Unreachable. (P008) Sehe ich nicht nur DNSv6 sondern auch eine IPv6-Adresse. Ich kenne mich mit dem ganzen Mist nicht aus, aber für mich sieht das schon danach aus, als ob da zumindest gerade jetzt IPv6 aktiv wäre. Das ließe sich ja, sofern der Anbieter das zulässt, mit 'nem Telefonanruf innerhalb von wenigen Stunden ändern (gerade neulich bei einem Kollegen mit Kabel Deutschland vorgekommen). Der hatte mit anderen Anwendungen ähnliche Probleme, die sich dadurch lösen lassen konnten. Aber vielleicht erzähle ich auch Blödsinn.
Gleissperre Posted October 7, 2015 Posted October 7, 2015 @JulianG: Nein, IPv6 kann parallel zu IPv4 genutzt werden. Der Provider und das Betriebssystem stellen immer** beides bereit, und die Programme selbst können dann entscheiden, welches von beiden sie nutzen.* Von daher ist das überhaupt kein Problem. * Sie könnten natürlich auch beide Nutzen. (Macht Signalsoft aber nicht.) ** Außer bei Uraltroutern (nur IPv4) und DS-Lite (nur IPv6)
Camore173 Posted October 7, 2015 Posted October 7, 2015 Also wenn man nach solchen Seiten wie http://test-ipv6.com/ gehen kann... dann habe ich beides. D.h. wenn ich den Post von Gleissperre richtig verstehe, dass meine Stellwerke und Supervisor eg. mit IPv4 arbeiten könnten... ? Oder verstehe ich das komplett falsch?
Gleissperre Posted October 7, 2015 Posted October 7, 2015 Genau. (Nur ist es gar nicht so einfach, DS-Lite zu dedektieren, weil die Provider mit DS-Lite noch ein paar Kompatiblitätsstufen einbauen, die aber im Falle von Signalsoft leider nicht greifen (können). Aber die Telekom ist mir ehrlich gesagt nicht dafür bekannt, zu wenig IPv4-Adressen zu haben, so dass es ganz Plausibel klingt, dass du beide vollwertige Adressen hast. Aber wie gesagt: Ich rechne im Moment eher damit, dass dein Router einfach nicht richtig in der Lage ist, sich selbst zu erreichen. Routerwechsel könnte möglicherweise helfen.)
Camore173 Posted October 14, 2015 Posted October 14, 2015 Hallo zusammen, heute hatte ich mal wieder Zeit und Lust das ganze zu Testen. Aufgefallen ist mir folgendes: Während ich eine Streckenverknüpfung "öffne" und die Ports teste erhalten ich dieses Ergebnis. 56390 offen Kein Standard-Port 57390 gefiltert Kein Standard-Port 57999 gefiltert Kein Standard-Port. Die Test Funktion sagt aber immer noch das die Ports erreichbar sind. Aber warum werden die UDP Ports gefiltert? Hat es damit was zu tun das ich im Supervisor nicht sichtbar bin? Wie kann ich das ändern. Ich habe für die UDP-Port Weiterleitung nichts anders gemacht als mit dem TCP Port? Gruß Camore
Gleissperre Posted October 14, 2015 Posted October 14, 2015 Wo genau steht "Port offen" bzw. "Port gefiltert"? Im Router oder von Signalsoft, wenn man auf die "Ports-Testen"-Schaltfläche klickt?
Camore173 Posted October 14, 2015 Posted October 14, 2015 Also auf der Port Test Schaltfläche von Signalsoft kommt immer "Test erfolgreich" - bei allen Ports, im Supervisor wie im Stellwerksprogramm. Das Ergebnis mit "Port gefiltert" habe ich von dieser Test Seite: http://www.four.heise.de/security/dienste/portscan
Gleissperre Posted October 14, 2015 Posted October 14, 2015 Der Test prüft nur auf TCP-Erreichbarkeit der Ports, und ob ein paar Hacks für diese Ports funktionieren. Im Prinzip ist das auch das, was die "Ports-Testen"-Schaltfläche macht, plus zusätzlich halt noch einen Test auf ein paar bekannte Hackerangriffsmuster. UDP wird von dem Test nicht erfasst. Für die Ports des Supervisors (57390 für das Programm und 57399 für den Supervisor selber) wird aber UDP benötigt. Desshalb zeigt der Test dort "gefiltert" an. Details zum Test siehe hier:http://www.heise.de/security/dienste/Testergebnisse-verstehen-475216.html Also im Prinzip nichts neues. Allerdings ist das ein weiteres Indiz darauf, dass es wohl "nur" an deinem Router liegt, der "die 180°-Kurve nicht verträgt". Wenn das tatsächlich daran liegt, dann hilft vielleicht ein umstieg auf eine Fritzbox. Gruß Gleissperre
Recommended Posts