Jump to content

Empfohlene Beiträge

Hallo zusammen,

hat noch jemand das Problem, dass der timeCard- Client nicht über eine VPN-Verbindung funktioniert?

Folgende Konfiguration ist vorhanden:

  • timeCard-Server: 192.168.2.XXX, Firewall deaktiviert, Portfreigaben in Virenscanner eingerichtet / testweise deaktiviert,
  • VPN-von Standort A (Subnet des timeCard-Server, s. o) zu Standort B; Subnet timeCard-Client) - alle Dienste/Services erlaubt.
  • PING / RDP, etc. funktionieren einwandfrei; nur der timeCard-Client nicht...

Woran kann es liegen ?

Gruß,

Sebastian

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Lösung:

 

Obwohl der Client bei dem ersten Start nach der IP des Servers fragt, muss der DNS-Name der Servers vom Client aufgelöst werden können!

Also entweder den Fehler im DNS-Server / der Namensauflösung suchen, oder einfach in der hosts-Datei des Clients einen entsprechenden Eintrag erstellen. ;)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Es kann noch eine Ursache geben, die mir aufgefallen ist:

Wenn der Client-PC mehrere aktive Netzwerk-Interfaces mit gültiger IPv4 Adresse hat, kann es sein daß der Client sich nicht öffnen lässt und mit einer Fehlermeldung "Anwendung kann nicht registriert werden [Interner Fehler]" abbricht. Die Ursache herfür ist, daß der Client sich am timeCard-Server mit einer aus den aktiven Netzwerkadaptern ermittelten IP-Adresse meldet. Ist diese aus einem anderen Netzsegment (z.B. weil auf dem Client noch Virtuelle Maschinen mit zugehörigen Host-Netzwerken installiert sind), so kann der Server dem Client auf der gemeldeten Adresse keine Rückmeldung geben. Nach einem Timeout von ca. 40 Sekunden bricht der Client dann mit der Fehlermeldung ab.

Gerade vor dem Hintergrund, daß bei einer aktiven VPN-Verbindung mehrere aktive Netzwerkadapter mit gültiger IPv4 Adresse im System vorhanden sind, könnte dieser Fehler auftreten.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Vielen Dank für den Hinweis! "Anwendung kann nicht registriert werden [Interner Fehler]" war die nächste Fehlermeldung, die ich erhalten habe. Nach deaktivierung aller ungenutzten Netzwerkverbindungen war der Fehler behoben. Gut zu wissen; ich habe mir die Finger wund gegoogelt und den Fehler gesucht....

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich habe zu dem Thema ein Screenvideo erstellt welches den Fehler verdeutlicht.

Zur Erklärung:
Der timeCard Client ist mit Java programmiert. Um mit dem Server zu kommunizieren benutzt er etwas das RMI (https://de.wikipedia.org/wiki/Remote_Method_Invocation) heißt. Dabei teilt der Client dem Server seine IP mit. Damit kann der Server dann dem Client Daten direkt senden, ohne daß der Client vorher die Daten anfordern musste (Callback Funktion). Damit dies aber reibungslos klappt muss einerseits die IP, welche der Client dem Server mitteilt, vom Server aus erreichbar sein. Dabei können auch Firewalls oder Virenscanner die Kommunikation blockieren.
Sind mehrere Netzwerkadapter auf dem Client-System aktiv und haben eine gültige IPv4 Adresse, nutzt der Client eine davon. Allerdings nicht unbedingt die erste oder die letzte.

Beispiel:
Der Client hat 2 Netzwerkadapter (Subnetzmasken lasse ich der Einfachheit halber mal weg):

  • Lokales Netz - 192.168.0.100
  • Abgekoppeltes Testnetz - 10.1.0.100

Der Server hat die IP 192.168.0.20.
Der Client verbindet sich nun mit dem Server (die IP des Servers nimmt er aus seinen Einstellungen) und teilt ihm die IP 10.1.0.100 mit, an jene der Server nun alle Rückmeldungen senden soll. Sogleich wartet der Client auf die erste Rückmeldung (nämlich daß die Mitteilung der IP geklappt hat). Der Server versucht nun dem Client auf 10.1.0.100 zu erreichen, was nicht klappt. Der Client wartet vergeblich auf die Rückmeldung.

Vorrübergehende Lösung:
Da Java RMI nicht von Reiner SCT selbst programmiert ist sondern bereits von Oracle mit Java mitgeliefert und nur noch im Client verwendet wird, kann man manche Parameter extern steuern. So sind z.B. in der Datei <Standard Installationspfad>\REINER SCT\timeCard\client\timeCard.ini einige Parameter angegeben:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20140603-1326
-vmargs
-Djava.util.Arrays.useLegacyMergeSort=true
-Dosgi.configuration.area=@user.home/RsctConf
-Dosgi.instance.area.default=@user.home/RsctWorkspace
-Dosgi.splashPath=platform:/base/plugins/com.reinersct.timeCard.start
-Declipse.product=com.reinersct.timeCard.start.product
-Declipse.application=org.eclipse.e4.ui.workbench.swt.E4Application

Dort kann man den Parameter java.rmi.server.hostname am Ende der Datei hinzufügen und diesem die IP oder den Hostname des Clients zuweisen:

-Djava.rmi.server.hostname=192.168.0.100

Damit nutzt der Client die IP/den Hostname welche/r hier angegeben ist und nicht die/den automatisch ermittelte/n.
(Dokumentation der Paramter: https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties.html)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Wunderbar! Ich danke Dir für die ausführliche Erklärung.

Der Workaround ist nett (und hilft natürlich ungemein!), jedoch denke ich, dass bei der Installation / bei dem ersten Programmstart neben der Abfrage der Server-IP bzw. DNS-Name ebenfalls aus oben genannten Gründen abgefragt werden soll, über welches Interface denn die Kommunikation mit dem Server stattfinden soll....

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 15 Stunden schrieb D12turb3d:

..., dass [...] bei dem ersten Programmstart [...] abgefragt werden soll, über welches Interface denn die Kommunikation mit dem Server stattfinden soll....

Nette Idee.
Viel eleganter wäre, wenn berechnet würde welche der IP-Adressen der vorhandenen Adapter in den gleichen Adressbereich fallen wie die IP des Servers.
Oder noch robuster wäre die Auswertung der Routing-Tabelle(n) des Clients.

Das sind zwar alles schöne Ideen aber offensichtlich gibt es zu wenige Anwender die dieses Problem wirklich haben und somit ist der Druck für die Programmierer nicht groß genug um dies zu implementieren. Daher vermute ich, dass mein Workaround den ich oben beschrieben habe ein dauerhaftes Provisorium bleiben wird.

Just my two cents... :-)

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

wir brauchen die funktionalität, das zwei nutzer sowohl aus dem lokalen netz als auch von zuhause aus mit der software arbeiten kann. 

gibts wirklich keine andere lösung, als das dann jedes mal händisch umzustellen? 

das muss doch besser gehen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


×
×
  • Neu erstellen...