Bug 1825484 - Cannot connect to RDP server
Summary: Cannot connect to RDP server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: remmina
Version: 32
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Pavel Alexeev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-18 13:18 UTC by Albert Flügel
Modified: 2020-07-10 17:45 UTC (History)
2 users (show)

Fixed In Version: remmina-1.4.7-1.fc32 remmina-1.4.7-1.fc31
Clone Of:
Environment:
Last Closed: 2020-07-09 01:05:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dialog showing, that remmina cannot connect (21.55 KB, image/png)
2020-07-03 19:52 UTC, Albert Flügel
no flags Details
Remmina dialog asking me an empty question to decide (18.62 KB, image/png)
2020-07-03 19:54 UTC, Albert Flügel
no flags Details
dialog showing, that remmina cannot connect fvia tls (25.70 KB, image/png)
2020-07-03 19:54 UTC, Albert Flügel
no flags Details
remmina offering me a super mini desktop (42.22 KB, image/png)
2020-07-03 19:56 UTC, Albert Flügel
no flags Details
Remmina dialog to configure resolutions (28.47 KB, image/png)
2020-07-03 19:56 UTC, Albert Flügel
no flags Details
remminas kiosk dialog with no obvious use (21.96 KB, image/png)
2020-07-03 19:57 UTC, Albert Flügel
no flags Details

Description Albert Flügel 2020-04-18 13:18:21 UTC
Description of problem:
Trying to connect to an RDP server via a gateway does not work.
The GUI says: Cannot connect to the "obfuscated-server-name" RDP server.


Version-Release number of selected component (if applicable):
1.4.1-1.fc31

How reproducible:


Steps to Reproduce:
1. Connect to an RDP based service using the appropriate URL in a browser and log in
2. Click a respective link, what leads to download of an RDP file (copy away the file for debugging after finding out it's path running ps -ef |grep -i remmina )
3. Try to login to the RDP session entering your credentials

Actual results:
After a few seconds, the program shows: Cannot connect to the "some-server-name" RDP server.

Expected results:
Window with the session opens


Additional info:
It works with xfreerdp, but i must pass it /cert-ignore .
Thus i suspected, that there is sth wrong with the certificate. However,
connecting to the gateway with openssl s_client -connect ...:443 i got a
successful SSL verification result. As a sidenote: i don't find any documentation, how to make additional certificates known to remmina/xfreerdp.
stracing showed, that it stat-s ~/.config/xfreerdp/certs , but when i copy the cacerts file there, it is not read.
In the internet i found, that in some remmina config GUI i can configure this switch, but i do not find anything related in the entire current remmina GUI now. I guess this has to do with a rework of it. It seems to me, in earler times remmina started xfreerdp as subprocess. Today it looks like it is linked with the remmina libraries and the respective option is not implemented.

I get as output from remmina:
Remmina plugin glibsecret (type=Secret) has registered but not yet initialized/activated. Initialization order is 2000.
Secret plugin glibsecret has been successfully initialized and will be your default secret plugin
Running under Gnome Shell version 3.34.5
[14:53:12:150] [5769:5774] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[14:53:12:151] [5769:5774] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[14:53:12:151] [5769:5774] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[14:53:12:151] [5769:5774] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[14:53:12:151] [5769:5774] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[14:53:12:497] [5769:5774] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[14:53:12:503] [5769:5774] [INFO][com.freerdp.core.nego] - Detecting if host can be reached locally. - This might take some time.
[14:53:12:504] [5769:5774] [INFO][com.freerdp.core.nego] - To disable auto detection use /gateway-usage-method:direct
[14:53:12:541] [5769:5774] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[14:53:24:475] [5769:5774] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
libfreerdp returned code is 800759DA

The return code indicates: E_PROXY_RAP_ACCESSDENIED
according to https://github.com/FreeRDP/FreeRDP/issues/4663 and https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-tsgu/84cd92e4-592c-4219-95d8-18021ac654b0?redirectedfrom=MSDN
But then why does it work with xfreerdp ?
Does remmina handle the credentials differently or what ?
What else might be helpful to debug ? I have an strace and the rdp file, what i cannot pass as is and need to anonymize first.

Comment 1 Albert Flügel 2020-05-24 18:14:42 UTC
By chance and from the coffee grounds i found, that when i set the "full address" to what i see in the "alternate full address" rdp file, remmina connects successful.
However, to say, what happens then, appears weird to me, is a compliment.
E.g. i get two buttons "Yes" and "No", but i have no idea, what the question is.
After connecting i get a remote desktop with a size of 640x480, very unpleasant to work with.
And i don't find any way to change the size of the remote desktop.
xfreerdp works. Why is remmina, what appears anything but mature to me, favoured as default in the fedora setup ?!?!?!?

Comment 2 Fedora Update System 2020-06-30 08:53:25 UTC
FEDORA-2020-dd8c133829 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd8c133829

Comment 3 Fedora Update System 2020-06-30 08:53:51 UTC
FEDORA-2020-a3ef998a70 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3ef998a70

Comment 4 Simone Caronni 2020-06-30 09:23:18 UTC
This upstream abandoned package has finally been retired, all other packages have moved to FreeRDP 2.x.
Nothing in Fedora or EPEL 7 require these libraries anymore.

Comment 5 Simone Caronni 2020-06-30 09:24:40 UTC
Sorry, closed the wrong ticket :)

The Remmina update that has been pushed now to Bodhi can be tested to see if this bug is fixed.

Comment 6 Fedora Update System 2020-07-01 02:09:50 UTC
FEDORA-2020-dd8c133829 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-dd8c133829`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd8c133829

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2020-07-01 02:19:03 UTC
FEDORA-2020-a3ef998a70 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a3ef998a70`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3ef998a70

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Albert Flügel 2020-07-03 19:52:56 UTC
Created attachment 1699886 [details]
dialog showing, that remmina cannot connect

Comment 9 Albert Flügel 2020-07-03 19:54:00 UTC
Created attachment 1699887 [details]
Remmina dialog asking me an empty question to decide

Comment 10 Albert Flügel 2020-07-03 19:54:44 UTC
Created attachment 1699888 [details]
dialog showing, that remmina cannot connect fvia tls

Comment 11 Albert Flügel 2020-07-03 19:56:26 UTC
Created attachment 1699889 [details]
remmina offering me a super mini desktop

Comment 12 Albert Flügel 2020-07-03 19:56:58 UTC
Created attachment 1699890 [details]
Remmina dialog to configure resolutions

Comment 13 Albert Flügel 2020-07-03 19:57:44 UTC
Created attachment 1699891 [details]
remminas kiosk dialog with no obvious use

Comment 14 Albert Flügel 2020-07-03 20:00:55 UTC
Regarding to what i reported, nothing has changed.

When i start remmina with the rdp file that comes from the
remotedesktop web page, a dialog opens, where i can enter
username, domain and password. Afterwards i get the window
shown in the attached screenshot remmina-cannot-connect.png
and can only close it.
(the screenshots are anonymized cause of privacy concerns)

Then i edit the rdp file and copy the value of the parameter
"alternate full address" to the parameter "full address", so
they look alike:

full address:s:myserver.mydomain.de
alternate full address:s:myserver.mydomain.de

Before, in "full address" there was the FQDN that can only
be resolved within the domain behind the gateway. I would
expect, remmina then takes the "alternate full address",
what works with xfreerdp, but it does obviously not.

Now with the official FQDN in the "full address" i get further.
I get the window shown in the attached remmina-yes-no.png .
Very helpful. What does it want from me ? (in the oranged-out
parts there is only the server FQDN) When i press no, the next
dialog will be the attached remmina-cannot-connect-tls.png
that - again - i can only close.

When i press YES in the yes-no-only-window, i get further.
Remmina asks me to confirm the certificate, then
a remote desktop opens, but with super-mini-screen. The
complete window is visible in the attached
remmina-rdp-fullscreen.png . The "desktop" size is i guess
640x480. Really ridiculous. It cannot be changed. Who can
work with that ? The screen size cannot be changed by
backend means. When i select the dialog from the desktop to
set the screen resolution i get the message from windows,
that from a remote session the resolution cannot be modified.
When i start remmina without rdp file, i can navigate to a
dialog to set possible screen resolutions, visible in the
attached remmina-resolutions-dialog.png . It is explained
nowhere, how to select from these. With the "Host key" + S
nothing happens. When i add the arguments
 --set-option resolution_mode=N
with any number 1 - 6 to the command line nothing changes.
What is this good for ? The host key has no effect with no
combination of any other shortcut that the configuration
settings imply.

Then i tried kisk mode, what comes with the hint "thin
client" and sounds like a simplified fullscreen login mode.
But no idea, what the window, that then appears is good for.
It is shown in remmina-kiosk-window.png . None of the widgets
is active except the entry, where i can write things, press
Enter or whatever, and nothing happens.

What my goodness is this all good for ?

In an earlier version that called xfreerdp in the back it
seemed to be possible to configure more things that are gone
now in favour of items that have no effect e.g. to set, whether
a certificate is accepted.

There is no widget to configure access to a local directory
in a remote drive (like possible with arguments to xfreerdp).
This is a crucial feature for any real productive work. Noone
hardly can go without this.
Same for local printers. Not so crucial, but would be nice,
especially as xfreerdp is already capable.

The manual page of remmina is more a rudiment. Where is the
documentation of the UI ?

So why would anyone use remmina and not xfreerdp ?
Can anyone explain me, why remmina is the default handler for
rdp files in Fedora ?
I don't understand it. Maybe i miss lots of things, but then
please someone give me the hints. Thank you.

Comment 15 Fedora Update System 2020-07-09 01:05:05 UTC
FEDORA-2020-a3ef998a70 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fedora Update System 2020-07-09 01:06:16 UTC
FEDORA-2020-dd8c133829 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 17 Albert Flügel 2020-07-10 17:45:26 UTC
Nothing has changed with remmina by upgrading to Fedora 32. Still the same weirdnesses, still all statements from above apply and also the screenshots.
How could have anything changed ? The version changed from 1.4.7-1.fc31 to 1.4.7-1.fc32 in other words it did not change.


Note You need to log in before you can comment on or make changes to this bug.