Welche Netzwerkvorkehrungen sind nötig für den Remote-Debugger

[TheSledgeHammer]

Hallo zusammen,

ich habe den PAServer vom RAD-Studio schon des häufigeren im Einsatz gehabt, bin also mit den Mechanismen soweit vertraut. Allerdings habe ich den Debugger bisher immer nur innerhalb der Firmen-Domäne eingesetzt und hier bin ich nie auf Netzwerkprobleme gestoßen.

Jetzt habe ich aber das Problem, dass in einer Tochtergesellschaft von uns ein Fehler auftritt, das ich debuggen muss. Die Tochtergesellschaft ist über einen VPN-Tunnel in unser Netzwerk integriert, d.h. der Rechner, auf dem ich das ganze Zeug starten muss, ist erreichbar und den kann ich via Remote-Zugriff auch ohne Probleme steuern. Ich habe unsere IT auch entsprechend gebeten, den Port 64211 überall freizuschalten, damit die Kommunikation funktioniert. Der Test im Profilmanager war auch erfolgreich. Von daher gehe ich mal davon aus, dass das im Prinzip nicht alles so verkehrt gewesen sein kann, was die da bisher getrieben haben.

Ich habe aber jetzt das Problem, dass die paserver.exe zwar alle Befehle vom RAD-Studio entgegen nimmt (wie gesagt, Test erfolgreich und auch die Dateien werden kopiert), aber leider bleibt der Debug-Prozess genau an der Stelle hängen, wo der PAServer den eigentlichen Remote-Debugger startet. Das Programm rmtdbg260.exe wird zwar noch ausgeführt, aber außer einer schwarzen Kommandozeile passiert nichts. Das endet dann in einem Timeout im RAD-Studio mit einer Fehlermeldung. Den genauen Wortlaut hab ich jetzt gerade nicht mehr parat, aber es ging drum, dass auf den Remote-PC nicht zugegriffen werden kann.

Ich für mein Teil weiß jetzt nicht, was wir da noch einstellen können, da in der gesmaten Doku zum Remote-Debuggen nichts weiter steht. Hatte von euch schon einmal jemand diese Problemstellung?

Besten Dank

[himitsu]

Viel gibt es eigentlich nicht, laut Doku.
Auf dem Zielrechner muß Port 64211 nach außen freigegeben sein (Portweiterleitung usw.), aber der kann auch geändert werden.
http://docwiki.embarcadero.com/RADSt...er_Application

Vielleicht Berechtigungen oder der Virenscanner auf dem Zielsystem?
Testweise die rmtdbg*.exe mal als Admin starten.



Ich hatte zwar zuletzt bissl Problemchen, wo ich unser Programm auf 'nem PC mit einer bestimmten Hardware testen wollte, wo aber "absichtlich" kein Delphi drauf ist, aber das war nur im Firmennetz durch zwei Fritzboxen und mit Delphi XE, wo sich die ganze Angelegenheit inzwischen ja schon ein Bissl verändert hat.
Aber durch das Internet vom RDP-Server ins lokale Netz war ich da auch nicht gekommen, obwohl es ja eigentlich hätte auch gehn sollen, nach Portfreigabe im Router. (von hier über RDP raus und durch's Internet zurück auf einen anderen PC im Intranet)

Eine andere Idee, aber die ich noch nicht verfolgen konnte, war durch ein VPN die beiden PCs zu verbinden (idealer Weise das vom TeamViewer).

[TheSledgeHammer]

Hallo,

ja die Doku habe ich bereits gewälzt, da steht tatsächlich nicht viel, was man an Vorkehrungen treffen müsste. Daher find ich das ja auch nicht raus, was die Kommunikation noch behindern sollte.

Also den Virenscanner kann ich an der Stelle ausschließen, da wir hier in der gesamten Firma den gleichen einsetzen und ich den testweise auch schon hab deaktivieren lassen. Aber das mit dem Admin probiere ich mal. Wobei ich sagen muss, dass ja der PAServer die rmtdbg-EXE startet und nicht ich von Hand. Aber den PAServer kann ich ja auch als Admin starten, vielleicht bringt das was.

Es könnte auch noch die Windows UAC sein, die es gewissen Programmen nicht erlaubt nach außen zu kommunizieren. Allerdings habe ich erwartet, dass dann vom Windows zumindest eine Abfrage kommt, von daher bin ich mir hier nicht ganz so sicher, ob's die tatsächlich sein kann.

[TurboMagic]

Mal prrobiert was passiert wenn man den PA Server auf dem Zielsystem startet
und in der Konsole dann "netstat -a -p TCP" eingegeben und geschaut was mit
diesem Port ist?

Im Zweifel auch mal die cmd mit Adminrechten starten und noch Parameter -b
beim Netstat mit dranhängen, dann zeigt er auch welche Datei den jeweiligen
Port anbietet, evtl. hat den ja schon ein anderes Programm belegt und der
PC Server meldet das nicht richtig?

[TheSledgeHammer]

Also der Hinweis mit dem Netstat war Gold wert, vielen Dank! Ich kenn mich mit solchen Tools leider nicht so gut aus, daher bin ich nicht auf die Idee gekommen, mal die Ports auch tatsächlich zu prüfen, die da neu aufgemacht werden.

Es ist - um es frei von der Leber weg zu sagen - eine Chuzpe, die Ihresgleichen sucht, was Emba da veranstaltet! Schön, dass man weiß, dass man den Port 64211 auf machen muss und auch schön, dass man den anpassen kann. Aber wieso ist hier nirgends dokumentiert, dass das ausschließlich für den PAServer gilt?! Die rmtdbg260.exe macht noch nen weiteren Port auf, den 64447, und der ist weder dokumentiert noch änderbar! Herzlichen Glückwunsch, kann ich da nur sagen! Das mosert dir der ach so tolle Verbindungsprofilmanager aber nicht an, wenn du die Verbindung testest, da kann man's auch gleich sein lassen!

Ich werde den Port jetzt auch noch öffnen lassen und dann schauen wir mal, ob das die Sache endlich bereinigt. Ich geb dann noch ne kurze Rückmeldung.

[Michael II]

Ist bei meinem 10.4 auch so.

Wenn ich auf dem entfernten Compi in der Firewall paserver.exe freigebe und starte, dann zeigt der Delphi "Verbindungsprofil Manager > Verbindung testen" "Alles OK" an.

Jedoch: Wenn ich meine App starte, dann zeigt Delphi die Fehlermeldung an:
Verbindung zu auf Port 64211 fehlgeschlagen.
Bitte überprüfen Sie, ob PAS auf dem Host-Computer ausgeführt wird und für die Verwendung von Port 64211 konfiguriert ist.

Es liegt aber nicht wie Delphi meldet an 64211/paserver.exe:
Sobald ich auf der entfernten Kiste rmtdbg270.exe in der Firewall freigebe, kann ich die App starten.

Delphi sollte also hier unbedingt eine korrekte Meldung ausgeben.

Du schreibst, dass 64447 weder änderbar noch dokumentiert sei. Beides ist anders: Infos findest du zum Beispiel hier hier.

[TheSledgeHammer]

Wenn's dokumentiert ist, dann ist's ja Ok, bleibt aber dennoch die falsche "Alles ist in Ordnung"-Meldung. Interessanterweise seh ich diese Seite zum ersten Mal, aber das kann auch an persönlicher Blindheit liegen Hab bei der Suche nach dem Port zwar natürlich auch was zum rmtdbg gelesen, aber diese Seite ist mir neu.

Edit
Ich find's aber auch nicht gut, dass man sowas an unterschiedlichen Stellen dokumentiert. Immerhin ist das einzige, mit dem man aus dem RAD-Studio heraus kommuniziert, der PAServer. Wie dieser dann im Hintergrund das rmtdbg-Programm startet wird ja wirklich nirgends erklärt, oder sehe ich das falsch? Und wenn es ja schon eine Konfigurationsdatei gibt, dann kann man doch hier auch noch einen dritten Parameter einbauen, in dem man den Port vom rmtdbg einstellen kann. Ist meines Erachtens einfach nicht sauber gemacht.

[TheSledgeHammer]

So, ich hab jetzt also auch noch den besagten Port 64447 freischalten lassen. Aber wenn ich ehrlich bin, hab ich auch nicht erwartet, dass das jetzt geht und was soll ich sagen: meine Erwartung wurde nicht enttäuscht.

Die Fehlermeldung, die jetzt kommt, hab ich mal als Anhang mit hier hoch geladen. Interessanterweise darf ich danach mein RAD Studio neustarten, weil dieser Fehler wohl ein schwerwiegender ist

Und auch wenn da was von "Proxy" steht, hab ich natürlich unseren Proxy deaktiviert bzw. umgangen. D.h. das können wir an der Stelle auch mal außer Acht lassen, zumindest was die Host-Anwendung angeht.

[Michael II]

Ich habe nie behauptet die Doku sei gut .
Da gehen 100Pro dutzende von Programmiererjahren drauf nur weil einer zu faul war, zum Thema eine zusammenhängende Doku anzufertigen.


- Der Installer von PAServer sollte einem anbieten die fürs Debuggen notwendigen Ports/Apps freizuschalten. (...und beim Deinstallieren wieder zu löschen.)
- Delphi sollte wie bereits erwähnt beim Testen der PAServer Verbindung (Delphi > Verbindungsprofil Manager) auch jene zum RemoteDebugger checken.
- Wenn man in Delphi die App startet und die Verbindung zum RemoteDebugger nicht aufgebaut werden kann: Delphi sollte eine korrekte Fehlermeldung anzeigen. Stand jetzt: Delphi zeigt die Falschmeldung an, die Verbindung zum PAServer klappe nicht.
- Wie du schreibst hängt Delphi bei jeder Gelegenheit rum oder sich auch gleich auf, wenn etwas nicht klappt beim Verbinden. Da werden wohl synchrone Verbindungsversuche mit überlangem Timeout im Hauptthread initiiert; beängstigend.

Zu deiner Fehlermeldung: Wie weiter oben erwähnt wurde:
- Hast du auf der entfernten Maschine geprüft, ob bereits eine andere App den Port 64447 nutzt? (netstat -b).
Am besten schreibst du dir eine Batch-Datei mit einer Zeile:
netstat -b > <filename>
Dann kannst du in <filename> die Remotedebugger exe suchen.
- Ab und zu läuft auf der entfernten Maschine noch ein RemoteDebugger. Wenn dann PAServer neu gestartet wird, dann klappt es nicht.
Hast du via TM geprüft, ob noch 1-viele RemoteDebugger laufen? Wenn ja, dann alle abschiessen und neu versuchen.
- Wenn du ohne Delphi die Verbidung zum RemoteDebugger testen willst, dann verwende zum Beispiel PowerShell. Starte auf dem entfernten Rechner den RemoteDebugger. Es sollte ein schwarzes Konsolenfenster angezeigt werden.
Prüfe auf dem entfernten Rechner mit netstat -b, ob der RemoteDebugger LISTENING ist.
Starte auf deinem Compi PowerShell und gib ein
test-netconnection -computername <entfernter-rechner> -port 64447

Beispiel: So sieht es aus, wenn die Verbingung nicht klappt, Ping aber OK ist (Firewall o.ä.):

Code:

PS C:\Users\micha> test-netconnection -computername swissjass.ch -port 64447
WARNUNG: TCP connect to (5.175.26.104 : 64447) failed


ComputerName           : swissjass.ch
RemoteAddress          : 5.175.26.104
RemotePort             : 64447
InterfaceAlias         : Netzwerkbrücke
SourceAddress          : 192.168.1.110
PingSucceeded          : True
PingReplyDetails (RTT) : 26 ms
TcpTestSucceeded       : False

Und so, wenn es klappt:

Code:

PS C:\Users\micha> test-netconnection -computername swissjass.ch -port 64447


ComputerName     : swissjass.ch
RemoteAddress    : 5.175.26.104
RemotePort       : 64447
InterfaceAlias   : Netzwerkbrücke
SourceAddress    : 192.168.1.110
TcpTestSucceeded : True

Viel Glück!

[TheSledgeHammer]

Also nur, weil das jetzt schon ein paar Tage ruht: ich bin noch an dem Thema dran aktuell haben wir aber ein paar Netzwerkprobleme, daher kann ich das seither nicht testen. Da kommt aber auf jeden Fall noch ein Update!