Bug 1640429
Summary: | rdesktop connection error | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rob Thomas <rwt> |
Component: | rdesktop | Assignee: | Jon Disnard <jdisnard> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | bvp713, cra, jdisnard, john.j5live, mclasen, oholy, rhughes, rstrode, sandmann, somlo |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | rdesktop-1.8.4-2.fc29 rdesktop-1.8.4-2.fc28 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-02-13 06:14:29 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rob Thomas
2018-10-18 03:45:56 UTC
I fired up a Windows 2012 R2 machine. rdesktop worked fine. I loaded a brand new F28 xfe server and loaded stock xrdp. No other updates, just xrdp. Same problem. I am having exactly the same problem. FWIW, the problem continues on Fedora 29. Have tried rdesktop from multiple F28/F29 clients to multiple xrdp F28 hosts. I have source and x86_64 RPMs for the latest git upstream (with an added software-mouse-jiggler out-of-tree patch) here: http://www.contrib.andrew.cmu.edu/~somlo/RDP/rdesktop-1.8.3-3.post.20181211git1f13bf5.fc28.src.rpm and mirror.ini.cmu.edu/gls/28/x86_64/rdesktop-1.8.3-3.post.20181211git1f13bf5.fc28.x86_64.rpm I'd be curious if this fixes the problem ? Hi. Thanks for the effort. I had to install libao-devel libsamplerate-devel pcsc-lite-devel, which is fine. Compiled without a problem and created the RPM. Installed it. So now it's asking me for a password on the command line instead of in the remote window. Wrong password, correct password, it just sits there until I hit control-c. Even for a real windows 2012 box. Thanks, Rob [robert@firefox ~]$ rdesktop -g 2460x1340 192.168.2.13 & [1] 7243 [robert@firefox ~]$ Autoselecting keyboard map 'en-us' from locale Password: [1]+ Stopped rdesktop -g 2460x1340 192.168.2.13 [robert@firefox ~]$ fg rdesktop -g 2460x1340 192.168.2.13 [robert@firefox ~]$ Does that for me as well. I use it like this: rdesktop -d MYDOMAIN -u myusername -p ' ' -f server.ip.address Haven't spent any cycles figuring out how to get it to *not* ask for a password on the terminal. Giving it the wrong one via cmdline gets me to where I have a chance to enter it again into a real windows login prompt. There's probably a proper way to do this, but I've been procrastinating ever since I found this silly workaround... Closer. At least it popped up an X window. Then blew it away. [robert@firefox ~]$ Autoselecting keyboard map 'en-us' from locale Protocol(error): tcp_tls_connect(), 0x1409442e:SSL routines:ssl3_read_bytes: tlsv1 alert protocol version Connection established using plain RDP. Clipboard(error): xclip_handle_SelectionNotify(), unable to find a textual target to satisfy RDP clipboard text request Clipboard(error): xclip_handle_SelectionNotify(), unable to find a textual target to satisfy RDP clipboard text request Sound(warning): rdpsnd_process_packet(), Unhandled opcode 0x27 disconnect: Unknown reason. Problem was between the keyboard and the chair. I had a session open from a Windows server. I really thought that VM host had been rebooted. It doesn't like it when I remote shell in again. So I terminated the windows session, tried again and poof. Comes right up. Comes right up with the Windows machine as well. The only change to the command line was the -p option. No password option, it won't work. so I believe the "must have -p" thing is an upstream regression of some sort, but I haven't yet worked up the courage to go and bisect it -- too scared of having to jump around the openssl 1.0 -> 1.1 switch while I'm at it :) (In reply to Gabriel Somlo from comment #8) > too scared of having to jump around the openssl 1.0 -> 1.1 switch while I'm at it :) Turns out I don't have to bisect, there's already a pull request to revert the "-p manadatory" thing: https://github.com/rdesktop/rdesktop/pull/216 And an argument between users and maintainers on the same topic here: https://github.com/rdesktop/rdesktop/issues/262 After some more experimentation, if I hit enter at the password prompt I get a failed login and the chance to enter it again via the destination machine's graphical password mechanism. Same thing happens if I use a space as the password ( "-p ' '"), my current workaround. Personally I think forcibly assuming "-p -" even in the absence of a -p command line flag is hostile to the user, but then again, that's not a surprise based on my past experience with rdesktop (see https://github.com/rdesktop/rdesktop/pull/23) :( User hostile, sure. Curious about the remote connection failing to work all of a sudden. Seems they would test before committing. rdesktop-1.8.4-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-5146cd34e2 rdesktop-1.8.4-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac70292cfc rdesktop-1.8.4-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac70292cfc rdesktop-1.8.4-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-5146cd34e2 rdesktop-1.8.4-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. The problem is still occurring. Even in a brand new install that has been updated. Brand new VM, brand new Desktop load. rdesktop-1.8.4-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. |