STS Zeitsystem Verbindungstest+IRC und Kontrollserver Fehler

[stevedoerr]

Hallo,

seit heute habe ich das Problem, dass bei mir immer der STS Zeitsystem Verbindungstest und der IRC und Kontrollserver Verbindungstest fehl schlägt. Ich habe an Java nicht verändert, ich hoffe mir kann jemand weiter helfen

[funy]

neu starten des sim?

[stevedoerr]

Ich kann das Java-Programm gar nicht starten, schon da wird abgebrochen

[Cunwad]

Neuer Antivirenscanner oder an der Firewall etwas verändert? Oder ganz allgemein, was hat sich verändert, seitdem es das letzte Mal ging? Es muss nicht an Java liegen. Meine Vermutung ist, dass bestimmte Ports geblockt werden, wenn keine Verbindung zum IRC aufgebaut werden kann.

[orloff]

Fehler ist mir bekannt.

Seit ich ein neues Notebook habe, kommt auch bei mir ein entsprechender Fehler.

Firewall des Systems ist aus, heimischer Router ist unverändert, und auch an einem anderen Standort funktioniert es nicht.

Konsolenausgabe nachfolgend:

12., 08:04:53
Dez 12, 2017 8:04:53 AM js.java.schaltungen.stsmain start
WARNUNG: Ohne einen Fehler ist eine Warnung nur eine Warnung und unkritisch.
Dez 12, 2017 8:04:53 AM js.java.schaltungen.stsmain start
INFORMATION: Ohne einen Fehler ist eine Information nur eine Information und unkritisch.

Build: 5679
Dez 12, 2017 8:04:53 AM com.sun.xml.internal.ws.wsdl.PayloadQNameBasedOperationFinder <init>
WARNUNG: Nicht eindeutige Textteile. Gemäß BP 1.1 R2710 müssen Vorgänge in einem Port eindeutige Vorgangssignaturen enthalten, damit die Verteilung erfolgreich verläuft. Methoden [storeLatency, getTip, isLoginAllowed, userConsole, getFriendFoe, userData, getName] haben denselben Anforderungstextblock {http://www.w3.org/2001/XMLSchema}string. Die Verteilung von Methoden verläuft möglicherweise nicht erfolgreich, die Laufzeitumgebung wird versuchen, die Verteilung mit SOAPAction vorzunehmen. Eine andere Möglichkeit besteht darin, AddressingFeature zu aktivieren, damit die Laufzeitumgebung WSDL-Vorgänge eindeutig mit wsa:Action-Header identifizieren kann.
Dez 12, 2017 8:04:53 AM com.sun.xml.internal.ws.wsdl.PayloadQNameBasedOperationFinder <init>
WARNUNG: Nicht eindeutige Textteile. Gemäß BP 1.1 R2710 müssen Vorgänge in einem Port eindeutige Vorgangssignaturen enthalten, damit die Verteilung erfolgreich verläuft. Methoden [storeLatency, getTip, isLoginAllowed, userConsole, getFriendFoe, userData, getName] haben denselben Anforderungstextblock {http://www.w3.org/2001/XMLSchema}string. Die Verteilung von Methoden verläuft möglicherweise nicht erfolgreich, die Laufzeitumgebung wird versuchen, die Verteilung mit SOAPAction vorzunehmen. Eine andere Möglichkeit besteht darin, AddressingFeature zu aktivieren, damit die Laufzeitumgebung WSDL-Vorgänge eindeutig mit wsa:Action-Header identifizieren kann.
Dez 12, 2017 8:04:53 AM js.java.schaltungen.verifyTests.v_timeserv test
SCHWERWIEGEND: null
java.security.AccessControlException: access denied ("java.net.SocketPermission" "46.165.212.222:3288" "connect,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:291)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1051)
at sun.nio.ch.DatagramChannelImpl.connect(DatagramChannelImpl.java:725)
at js.java.isolate.sim.timesystem.timeSync.init(timeSync.java:91)
at js.java.isolate.sim.timesystem.timeSync.<init>(timeSync.java:53)
at js.java.schaltungen.verifyTests.v_timeserv.test(v_timeserv.java:34)
at js.java.schaltungen.verifyTests.InitTestBase.runtest(InitTestBase.java:34)
at js.java.schaltungen.StartVerify.runTests(StartVerify.java:115)
at js.java.schaltungen.StartVerify.access$000(StartVerify.java:25)
at js.java.schaltungen.StartVerify$1.run(StartVerify.java:100)
at java.lang.Thread.run(Thread.java:748)


12., 08:05:04
Dez 12, 2017 8:05:04 AM de.deltaga.eb.BasicEventBus publish
INFORMATION: No subscriber for js.java.schaltungen.chatcomng.ChatUser
Dez 12, 2017 8:05:04 AM de.deltaga.eb.BasicEventBus publish
INFORMATION: No subscriber for js.java.schaltungen.chatcomng.ChatUser
Dez 12, 2017 8:05:04 AM de.deltaga.eb.BasicEventBus$HandlerInfoCallable call
SCHWERWIEGEND: Event Handler exception on handler Class: js.java.schaltungen.chatcomng.IrcConnectedEvent, Call: public void js.java.schaltungen.stsmain.ircConnected(js.java.schaltungen.chatcomng.IrcConnectedEvent) with event js.java.schaltungen.chatcomng.IrcConnectedEvent@72262544
java.security.AccessControlException: access denied ("java.net.SocketPermission" "46.165.212.222:3288" "connect,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:291)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1051)
at sun.nio.ch.DatagramChannelImpl.connect(DatagramChannelImpl.java:725)
at js.java.isolate.sim.timesystem.timeSync.init(timeSync.java:91)
at js.java.isolate.sim.timesystem.timeSync.<init>(timeSync.java:53)
at js.java.schaltungen.chatcomng.GlobalLatency.<init>(GlobalLatency.java:42)
at js.java.schaltungen.stsmain.ircConnected(stsmain.java:320)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at de.deltaga.eb.BasicEventBus$HandlerInfoCallable.call(BasicEventBus.java:674)
at de.deltaga.eb.BasicEventBus$2.run(BasicEventBus.java:428)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Dez 12, 2017 8:05:04 AM js.java.schaltungen.stsmain busEvent
SCHWERWIEGEND: null
java.security.AccessControlException: access denied ("java.net.SocketPermission" "46.165.212.222:3288" "connect,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:291)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1051)
at sun.nio.ch.DatagramChannelImpl.connect(DatagramChannelImpl.java:725)
at js.java.isolate.sim.timesystem.timeSync.init(timeSync.java:91)
at js.java.isolate.sim.timesystem.timeSync.<init>(timeSync.java:53)
at js.java.schaltungen.chatcomng.GlobalLatency.<init>(GlobalLatency.java:42)
at js.java.schaltungen.stsmain.ircConnected(stsmain.java:320)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at de.deltaga.eb.BasicEventBus$HandlerInfoCallable.call(BasicEventBus.java:674)
at de.deltaga.eb.BasicEventBus$2.run(BasicEventBus.java:428)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Test mit Telnet gibt gleiches Problem von 3 verschiedenen Standorten:

telnet 46.165.212.222 3288
Trying 46.165.212.222...
telnet: Unable to connect to remote host: Verbindungsaufbau abgelehnt

[hinz]

Hi,

ja nun, das klingt doch recht eindeutig, nicht wahr? Irgendetwas auf Deinem Notebook/in Deinem Netzwerk verhindert die Verbindung. In der Regel ist das eine Firewall oder eine Sicherheits-Suite.

Servus
Heinz

[orloff]

Und auch für den Herrn "Hinz" nochmal.

Getestet wurde die Verbindung von 3 unteschiedlichen Geräten per "Telnet-Befehl".
3 Unterschiedliche Geräte in unterschiedlichen Netzwerken ohne ein Problem bei anderen ausgehenden Verbindungen.

Aus genau diesem Grund schließe ich ja das Firewall-/Rechnerproblem aus.

[DLichti]

Getestet wurde die Verbindung von 3 unteschiedlichen Geräten per "Telnet-Befehl".

Und was genau versuchst du damit zu testen? Telnet ist einer der letzten Dienste, die auf einem öffentlich, produktiv eingesetzten Server erreichbar sein sollte. (Ein kurzer Test zeigt, dass er es tatsächlich nicht ist, weder auf dem Standardport, noch auf 3288. Der Simulator funktioniert trotzdem.)

Edith meint: Wenn du testen willst, ob ein Server erreichbar ist, dann ist

Code: Alles auswählen

ping stellwerksim.de

eher angebracht. In deinem Fall scheint das aber nicht das Problem zu sein, da der Test bereits von den Java-Policies abgewürgt wird.

David

[abrixas]

Telnet (Client) ist ein wunderbares Tool um zu testen ob ein Rechner auf einem TCP-Port hört, bei UDP-Ports gehts in die Hose ...

[hinz]

Und auch für den Herrn "Hinz" nochmal.

Getestet wurde die Verbindung von 3 unteschiedlichen Geräten per "Telnet-Befehl".
3 Unterschiedliche Geräte in unterschiedlichen Netzwerken ohne ein Problem bei anderen ausgehenden Verbindungen.

Aus genau diesem Grund schließe ich ja das Firewall-/Rechnerproblem aus.

Und wenn ein öffentlich verfügbarer Dienst, der bei allen anderen funktioniert per telnet von Dir aus nicht erreichbar ist, schließt Du daraus, dass bei Dir kein Problem bestehen kann? Na von mir aus, bei dem Ton bin ich eh raus.

Servus
Heinz

[orloff]

OK, nochmals genauer mit Java auseinandergesetzt, und eine Lösung gefunden.

Bearbeiten der "Java.Policy"-Datei hat dann doch den Erfolg gebracht, obwohl die "alte" Datei den gleichen Inhalt hatte.
Könnte aber durchaus ein Problem mit einem Update gewesen sein.

Also für alle, die in ein ähnliches Problem fallen, die Datei "java.policy" bearbeiten. Bei Linux potentiell befindlich unter "/etc/java-8-openjdk/security/java.properties"
Folgenden Eintrag im Bereich "grant" einfügen:

Code: Alles auswählen

permission java.net.SocketPermission "46.165.212.222:3288", "connect, resolve";

Danach funktioniert bei mir die Verbindung wieder.

[sbem]

Ich hatte das gleiche Problem auf Debian. Bei mir hat es geholfen in der Datei

Code: Alles auswählen

/etc/java-8-openjdk/security/java.policy

den Inhalt

Code: Alles auswählen

        // Permissions für Stellwerksim
        permission java.net.SocketPermission "www.stellwerksim.de", "connect,accept,resolve";
        permission java.net.SocketPermission "46.165.212.222:3288", "connect,resolve";

am Ende aber innerhalb der

Code: Alles auswählen

grant { }

Direktive einzufügen. Danach hat der Funktionstest geklappt.

[Paiero]

Liebe Stellwerksim-Gemeinde,

heute wollte ich nach längerer Zeit mal wieder das Spiel starten, habe jedoch die gleichen Probleme wie oben beschrieben.

D.h. STS Zeitsystem Verbindungstest und IRC & Kontrollserver Verbindungstest leuchten rot. Mehrmaliges starten innerhalb der letzten Stunde haben keinen Erfolg gebracht. Die Tipps zum ändern der Java.Policy von den Vorpostern habe ich versucht umsetzen, allerdings wurde mir der Zugriff verweigert (kann man das ändern?).

In andere Threads hatte sich das Problem von selbst erledigt, ich vermute aber selber, dass es was mit dem Router-System zu tun hat, da dieser Fehler jetzt das erste Mal auftritt, seitdem ich das WLAN-Netzwerk "Eduroam" (Uni-Campus) nutzen muss. Gibt es dazu vielleicht etwaige Erfahrungswerte?

Build: 5703
Java: 1.8.0_191; Java HotSpot(TM) Client VM
Runtime: Java(TM) SE Runtime Environment; 1.8.0_191-b12
Arch: 32; running on x86; 4 cores
OS: Windows 7; version 6.1
VM Memory: 483 MB max; 483 MB used
User: Paiero UID: 35776
IPv6: false


25., 12:55:08
Nov 25, 2018 12:55:08 PM js.java.schaltungen.stsmain start
WARNUNG: Ohne einen Fehler ist eine Warnung nur eine Warnung und unkritisch.
Nov 25, 2018 12:55:08 PM js.java.schaltungen.stsmain start
INFORMATION: Ohne einen Fehler ist eine Information nur eine Information und unkritisch.

Build: 5703
Nov 25, 2018 12:55:09 PM com.sun.xml.internal.ws.wsdl.PayloadQNameBasedOperationFinder <init>
WARNUNG: Nicht eindeutige Textteile. Gemäß BP 1.1 R2710 müssen Vorgänge in einem Port eindeutige Vorgangssignaturen enthalten, damit die Verteilung erfolgreich verläuft. Methoden [getName, userData, getTip, storeLatency, isLoginAllowed, eventOccured, userConsole, getFriendFoe] haben denselben Anforderungstextblock {http://www.w3.org/2001/XMLSchema}string. Die Verteilung von Methoden verläuft möglicherweise nicht erfolgreich, die Laufzeitumgebung wird versuchen, die Verteilung mit SOAPAction vorzunehmen. Eine andere Möglichkeit besteht darin, AddressingFeature zu aktivieren, damit die Laufzeitumgebung WSDL-Vorgänge eindeutig mit wsa:Action-Header identifizieren kann.
Nov 25, 2018 12:55:10 PM com.sun.xml.internal.ws.wsdl.PayloadQNameBasedOperationFinder <init>
WARNUNG: Nicht eindeutige Textteile. Gemäß BP 1.1 R2710 müssen Vorgänge in einem Port eindeutige Vorgangssignaturen enthalten, damit die Verteilung erfolgreich verläuft. Methoden [getName, userData, getTip, storeLatency, isLoginAllowed, eventOccured, userConsole, getFriendFoe] haben denselben Anforderungstextblock {http://www.w3.org/2001/XMLSchema}string. Die Verteilung von Methoden verläuft möglicherweise nicht erfolgreich, die Laufzeitumgebung wird versuchen, die Verteilung mit SOAPAction vorzunehmen. Eine andere Möglichkeit besteht darin, AddressingFeature zu aktivieren, damit die Laufzeitumgebung WSDL-Vorgänge eindeutig mit wsa:Action-Header identifizieren kann.


Aus der Console kann ich nichts erkennen, bin aber auch kein Fachmann .

Wäre um jeden Tipp dankbar!

[abrixas]

Einige Einrichtungen sperren im Eduroam ausgehend/eingehend bestimmte Ports, die in der Vergangenheit für nicht gewollte Verbindungen benutzt wurden.
Infos zu notwendigen Ports findest du im Handbuch.

Die Tipps zum ändern der Java.Policy von den Vorpostern habe ich versucht umsetzen, allerdings wurde mir der Zugriff verweigert (kann man das ändern?).

Möglicherweise hast du nicht die erforderlichen rechte auf diesem System.

Gruß
abrixas

[DLichti]

In andere Threads hatte sich das Problem von selbst erledigt, ich vermute aber selber, dass es was mit dem Router-System zu tun hat, da dieser Fehler jetzt das erste Mal auftritt, seitdem ich das WLAN-Netzwerk "Eduroam" (Uni-Campus) nutzen muss. Gibt es dazu vielleicht etwaige Erfahrungswerte?

Wenn du aus so einem großen Netz zugreifst, dann könnte es auch passieren, dass schon jemand anders über die selbst externe IP verbunden ist. Bin mir aber nicht sicher, wie dann die Fehlermeldung aussehen würde.

David