Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionAndrei Stepanov
2015-03-23 12:55:29 UTC
Description of problem:
xfreedp fails to connect remote windows machine, win7, 2008, ...
however, it can connect to WinXP
Version-Release number of selected component (if applicable):
freerdp-plugins-1.0.2-5.el7.s390x
How reproducible:
in terminal try to connect to Windows7
Steps to Reproduce:
1. $ xfreerdp -u x -p x remote_host
Actual results:
connected to x:3389
SSL_read: Failure in SSL library (protocol error?)
Authentication failure, check credentials.
If credentials are valid, the NTLMSSP implementation may be to blame.
It works correctly for me with x86_64, is it ppc64/s390x specific? Does other architectures works for you also? Does it help when you force e.g. rdp authentication method --sec rdp (or tls), or disable nla using --no-nla?
Are you sure the credentials are correct? Don't you have expired passwords?
https://support.microsoft.com/en-us/kb/2648397
Bug is ppc64/s390x specific.
--no-nla - helps establish connection to remote machine
--sec rdp - also works
--sec tls - also works
x86_64 does not require to use such flags.
It is really weird that it fails only on those architectures, is there anything specific only for them?
There is call log where xfreerdp fails if somebody wants to debug it:
#1 0x00003fffb7e6aa08 in tls_read (tls=0x3fffa8002980, data=<optimized out>, length=<optimized out>) at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/tls.c:152
#2 0x00003fffb7e6d93c in transport_read (transport=0x100c3060, s=0x100c7160) at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/transport.c:181
#3 0x00003fffb7e4e4fc in credssp_recv (credssp=0x3fffa8032670, negoToken=0x3fffa8032670, authInfo=0x0, pubKeyAuth=0x3fffa8032680)
at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/credssp.c:554
#4 0x00003fffb7e4e8dc in credssp_authenticate (credssp=0x3fffa8032670) at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/credssp.c:194
#5 0x00003fffb7e6d6a4 in transport_connect_nla (transport=0x100c3060) at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/transport.c:118
#6 0x00003fffb7e658d8 in rdp_client_connect (rdp=0x100c1220) at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/connection.c:91
#7 0x00003fffb7e5e47c in freerdp_connect (instance=0x100c1090) at /usr/src/debug/freerdp-1.0.2/libfreerdp-core/freerdp.c:49
#8 0x0000000010014450 in xfreerdp_run (instance=0x100c1090) at /usr/src/debug/freerdp-1.0.2/client/X11/xfreerdp.c:979
#9 0x000000001001481c in thread_func (param=0x100e5810) at /usr/src/debug/freerdp-1.0.2/client/X11/xfreerdp.c:1091
#10 0x00003fffb768c26c in start_thread (arg=0x3fffb06af0d0) at pthread_create.c:310
#11 0x00003fffb75a8080 in .__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:111
SSL_read returns SSL_ERROR_SSL, so it is probably bug in openssl.
(In reply to Ondrej Holy from comment #5)
> It is really weird that it fails only on those architectures, is there
> anything specific only for them?
Maybe there is problem with big endian in freerdp, because it seems openssl works correctly for other applications on those architectures...
Several big endian fixes have been merged by upstream, those fixes also fix this issue. I think it should be possible to backport them:
https://github.com/FreeRDP/FreeRDP/pull/3284
However, I don't think it makes sense to backport those fixes without fixing Bug 1308810, because colors are corrupted on big endian machines anyway...
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0724