21
Xfreerdp-Experten zu Hilfe!
Moin Kollegen!
Ich habe hier ein hässliches Problem.
Wir nutzen eine Linux-VPN-Lösung, welche von einem Bootstick aus arbeitet und xfreerdp verwendet, um den Büro-PC fernzusteuern.
Problem: zu einem geringen Teil der Ziel-Rechner verbindet sich dieser Client genau 1x. Will der User später ein weiteres mal rein, erhält er die Fehlermeldung
Das passiert wie gesagt nur bei wenigen Rechnern und die haben außer Win10 auch nicht viel gemeinsam, was man als Ursachen ausmachen könnte.
Gut, nun zur witzigen Beobachtung: Intern kann ich zu diesen PCs auch im Fehlerzustand problemlos durchgängig RDP machen, solange ich den Windows-RDP-Client (mstsc.exe) verwende.
Aber mit freexrdp jedoch bekomme ich auch hausintern im LAN den selben Fehler, somit hat es mit dem VPN mal rein gar nichts zu tun.
Es wird noch besser: deinstalliere ich auf solche einer Zielmaschine den Grafikkartentreiber (egal, ob Intel oder Nvidia oder AMD xy), dann geht es weiterhin nicht. installiere ich ihn jedoch wieder und starte nicht wie empfohlen neu, kann man sich wieder genau 1x verbinden, dann geht der Müll von vorne los!
Was ist das denn bitte? Was tut xfreerdp der Zielmaschine an, was mstsc.exe nicht macht?
Der Herstellersupport beißt sich derzeit die Zähne daran aus.
Hat jemand hier Ahnung von xfreerdp? Falls ihr diesen speziellen Fehler kennt, meldet Euch bitte.
Wenn nicht, dann lasst gut sein
Ich habe hier ein hässliches Problem.
Wir nutzen eine Linux-VPN-Lösung, welche von einem Bootstick aus arbeitet und xfreerdp verwendet, um den Büro-PC fernzusteuern.
Problem: zu einem geringen Teil der Ziel-Rechner verbindet sich dieser Client genau 1x. Will der User später ein weiteres mal rein, erhält er die Fehlermeldung
ERRINFO_CLOSE_STACK_ON_DRIVER_FAILURE_STRING
"The display driver in the remote session was unable to complete all the tasks required for startup."
"The display driver in the remote session was unable to complete all the tasks required for startup."
Das passiert wie gesagt nur bei wenigen Rechnern und die haben außer Win10 auch nicht viel gemeinsam, was man als Ursachen ausmachen könnte.
Gut, nun zur witzigen Beobachtung: Intern kann ich zu diesen PCs auch im Fehlerzustand problemlos durchgängig RDP machen, solange ich den Windows-RDP-Client (mstsc.exe) verwende.
Aber mit freexrdp jedoch bekomme ich auch hausintern im LAN den selben Fehler, somit hat es mit dem VPN mal rein gar nichts zu tun.
Es wird noch besser: deinstalliere ich auf solche einer Zielmaschine den Grafikkartentreiber (egal, ob Intel oder Nvidia oder AMD xy), dann geht es weiterhin nicht. installiere ich ihn jedoch wieder und starte nicht wie empfohlen neu, kann man sich wieder genau 1x verbinden, dann geht der Müll von vorne los!
Was ist das denn bitte? Was tut xfreerdp der Zielmaschine an, was mstsc.exe nicht macht?
Der Herstellersupport beißt sich derzeit die Zähne daran aus.
Hat jemand hier Ahnung von xfreerdp? Falls ihr diesen speziellen Fehler kennt, meldet Euch bitte.
Wenn nicht, dann lasst gut sein
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 630614
Url: https://administrator.de/contentid/630614
Printed on: April 19, 2024 at 21:04 o'clock
21 Comments
Latest comment
Scheint nicht ganz unbekannt zu sein...
https://github.com/FreeRDP/FreeRDP/issues/5548
https://github.com/FreeRDP/FreeRDP/issues/5548
Moin...
welche den?
Frank
Wir nutzen eine Linux-VPN-Lösung, welche von einem Bootstick aus arbeitet und xfreerdp verwendet, um den Büro-PC fernzusteuern.
welche den?
Frank
Welche? Ecos SBS
@aqui
Interessant. Allerdings ist das anders, denn hier komme ich auch nicht rein, wenn alle Sitzungen beendet sind.
Interessant. Allerdings ist das anders, denn hier komme ich auch nicht rein, wenn alle Sitzungen beendet sind.
Steps to get around the problem: if you sign the user out in step 2, then you will get the user session in step 3
@aqui
Nebenbei bemerkt: alle in dem Thread genannten Einstellungen sind schon erfolglos getestet worden.
Nebenbei bemerkt: alle in dem Thread genannten Einstellungen sind schon erfolglos getestet worden.
Moin,
Ich bin mir gerade nicht sicher, ob unsere Igel-ThinClients auch mit xfreerdp arbeiten, das reiche ich dir noch nach.
Aber, kannst du die Version des Clients beeinflussen?
Warum ich frage:
Ich weiß z.B. dass Igel selten die aktuellsten Clients einsetzt und eher auf ausgereifte Versionen setzt und bei uns rennt der Igel mit RDP fehlerfrei.
Bei Ecos SBS hab ich diesbezüglich jedoch 0 Ahnung.
Habt ihr schon viele von den Dingern aktiv?
Auch wenn das deine eigentliche Frage nicht beantwortet und ich weiß, dass du von abschweifenden Antworten (nachvollziehbar) eher absiehst:
Wäre als Alternative Igels PocketUD denkbar. Den könnt ihr zentral voll vorkonfigurieren, auch dass der beim Boot 'nen VPN und dann die RDP-Verbindung aufbaut oder zumindest nach Anmeldedaten fragt, bevor er weiterläuft.
https://www.igel.de/wp-content/uploads/2017/07/UD_Pocket_QA_166-DE-31-1. ...
Edit:
Die Igel-ThinClients auf Unix-Basis nutzen den 2XClient von Parallels.
Dann ist meine Aussage von oben für dich wenig hilfreich, außer du kannst den 2XClient auf den EcoSBS-Sticks einsetzen.
Ich halte mich dann hier mal weiter zurück , außer du schreist nach mehr Infos
Edit2:
Habe gerade den hier noch gefunden, welcher jünger denn @aqui sein Link ist
https://github.com/FreeRDP/FreeRDP/issues/6225
Könnte ggf. ein NTLM-/ Kerberos-Problem sein
Gruß
em-pie
Ich bin mir gerade nicht sicher, ob unsere Igel-ThinClients auch mit xfreerdp arbeiten, das reiche ich dir noch nach.
Aber, kannst du die Version des Clients beeinflussen?
Warum ich frage:
Ich weiß z.B. dass Igel selten die aktuellsten Clients einsetzt und eher auf ausgereifte Versionen setzt und bei uns rennt der Igel mit RDP fehlerfrei.
Bei Ecos SBS hab ich diesbezüglich jedoch 0 Ahnung.
Habt ihr schon viele von den Dingern aktiv?
Auch wenn das deine eigentliche Frage nicht beantwortet und ich weiß, dass du von abschweifenden Antworten (nachvollziehbar) eher absiehst:
Wäre als Alternative Igels PocketUD denkbar. Den könnt ihr zentral voll vorkonfigurieren, auch dass der beim Boot 'nen VPN und dann die RDP-Verbindung aufbaut oder zumindest nach Anmeldedaten fragt, bevor er weiterläuft.
https://www.igel.de/wp-content/uploads/2017/07/UD_Pocket_QA_166-DE-31-1. ...
Edit:
Die Igel-ThinClients auf Unix-Basis nutzen den 2XClient von Parallels.
Dann ist meine Aussage von oben für dich wenig hilfreich, außer du kannst den 2XClient auf den EcoSBS-Sticks einsetzen.
Ich halte mich dann hier mal weiter zurück , außer du schreist nach mehr Infos
Edit2:
Habe gerade den hier noch gefunden, welcher jünger denn @aqui sein Link ist
https://github.com/FreeRDP/FreeRDP/issues/6225
Könnte ggf. ein NTLM-/ Kerberos-Problem sein
Gruß
em-pie
Hallo,
versuch mal "Prioritize H.264/AVC 444 Graphics mode for Remote Desktop connections" auf disabled.
Grüße
Richard
versuch mal "Prioritize H.264/AVC 444 Graphics mode for Remote Desktop connections" auf disabled.
Grüße
Richard
@em-pie
Das Verlinkte sehe ich in keinem Zusammenhang. Außer, dass auch xfreerdp genutzt wird, keine Gemeinsamkeiten.
Zu Ecos, ja, wir haben seit einigen Jahren >30 Ecos Sticks aktiv. Versionen können wir nicht beeinflussen. Das Problem hatten wir schon vor 2 Jahren, da habe ich den Rechner neu installiert, da wir das Problem nicht finden konnten. Nun haben es ein paar mehr Rechner (Windows wurde seitdem natürlich auch upgegradet).
Die Igellösung wird nichts, da wir ein vom BSI bis mindestens VS-NfD zugelassenes VPN nutzen müssen
@c.r.s.
Das hat keinen Unterschied gemacht.
Das Verlinkte sehe ich in keinem Zusammenhang. Außer, dass auch xfreerdp genutzt wird, keine Gemeinsamkeiten.
Zu Ecos, ja, wir haben seit einigen Jahren >30 Ecos Sticks aktiv. Versionen können wir nicht beeinflussen. Das Problem hatten wir schon vor 2 Jahren, da habe ich den Rechner neu installiert, da wir das Problem nicht finden konnten. Nun haben es ein paar mehr Rechner (Windows wurde seitdem natürlich auch upgegradet).
Die Igellösung wird nichts, da wir ein vom BSI bis mindestens VS-NfD zugelassenes VPN nutzen müssen
@c.r.s.
Das hat keinen Unterschied gemacht.
Welche Paramenter nutzt denn der Aufruf von xfreerdp?
So simpel wie nur geht: /u /p /v -sec-nla
Kannst Du /gfx:AVC420 hinzufügen? /gfx /rfx und gfx:444 wie in Aquis Link passen nicht auf Nicht-RemoteFX-Verbindungen. Mit /gfx:AVC420 entspricht es dem MS-RDP-Standardverhalten. Es muss sich ein Unterschied in der Video-Wiedergabe zeigen, sonst hat es der Hersteller ggf. angepasst.
Nee, das bietet der Client nicht.
Auch auf einem aktuellen SuSe Leap kann ich bei freerdp keine Option /gfx:AVC420 finden, nebenbei bemerkt, sonst könnte ich es wenigstens dort testen. Auf welchem System hast Du diese Option?
Auch auf einem aktuellen SuSe Leap kann ich bei freerdp keine Option /gfx:AVC420 finden, nebenbei bemerkt, sonst könnte ich es wenigstens dort testen. Auf welchem System hast Du diese Option?
Bei der Installation aus dem Debian-Repo ist das dabei. Die gfx, gfx-h264 und gfx-progressive Parameter würde ich alle mal ausprobieren.
Hast Du die URL des Repositories für mich?
Für die sources.list:
deb http://deb.debian.org/debian/ buster main
deb http://deb.debian.org/debian/ buster main
Es haben sich durch Tests weitere Erkenntnisse ergeben, die nahelegen, dass das Problem viel grundlegender ist. Es liegt zumindest nicht an Schaltern für xfreerdp. Werde nach dem Weihnachtsurlaub erst weitermachen können.
Danke für den Link, @c.r.s.
Danke für den Link, @c.r.s.
Folgendes hat es gelöst:
Wenn man am Heimsystem (Ecos-Linux) die MTU-Size der Verbindung herabsetzt (von "Auto" auf 1300), läuft alles wie geschmiert!
Erstaunlich, aber das hat es bei allen Betroffenen gelöst.
Wenn man am Heimsystem (Ecos-Linux) die MTU-Size der Verbindung herabsetzt (von "Auto" auf 1300), läuft alles wie geschmiert!
Erstaunlich, aber das hat es bei allen Betroffenen gelöst.
1
Auf die Lösung muss man erst einmal kommen - im Nachgang aber auch nachvollziehbar.
Danke dir der Rückmeldung!
Danke dir der Rückmeldung!
Vor allem das die MTU auch im internen LAN scheinbar relevant ist... Darauf wäre wohl im ersten Ansatz in der Tat niemand gekommen...
Dank fürs Feedback !
Dank fürs Feedback !
Vor allem das die MTU auch im internen LAN scheinbar relevant ist.
Im LAN war diese Änderung nicht nötig. Was ich über die Merkwürdigkeit im LAN schrieb: das war nicht immer reproduzierbar und ist vermutlich auch jetzt noch gelegentlich anzutreffen.
Ok, danke für die Klarstellung. Das wäre auch in der Tat recht ungewöhnlich wenn im LAN die MTU sowas gefixt hätte.
