| Summary: | Confusion (blue screen) when establishing connection (RDP, VNC to some degree) | ||
|---|---|---|---|
| Product: | [Applications] krdc | Reporter: | Philippe Cloutier <chealer> |
| Component: | general | Assignee: | Urs Wolfer <uwolfer> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | major | CC: | acelan, b-misc, dima, hitori.gm, justin.zobel |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Philippe Cloutier
2014-09-28 21:44:05 UTC
I can reproduce this issue when I cancel the password prompt. This is a bug. Also when I enter an RDP address, which does not resolve to an RDP server, the blue screen stays there... Basically the blue screen should be visible while a connection is established. Once the connection is established, the blue screen gets replaced with the client view. If there is an error, the error should be displayed to the user. The disconnect-button is there as soon as a connection tab is opened (it's basically an action to close the tab). But I agree, it can be confusing when it's called disconnect when no connection has been opened. Do you know other error-cases where no error message box is displayed (but instead the blue screen stays there)? *** Bug 331990 has been marked as a duplicate of this bug. *** Addition to my comment above: the blue screen only stays there when using xfreerdp 1.1. With 1.0 connection errors are displayed. Same issue on Arch Linux (kdenetwork-krdc 4.14.3-1). Unfortunately no errors or any output when this happens. freerdp 1.2.0_beta1+android9-1 (latest) — blue screen freerdp 1.1.0_beta+2013071101-1 — works fine freerdp 1.0.2-7 — works fine This bug already happens with Debian's FreeRDP 1.0.2-4. However, comment 3 is correct in so far as error reporting is better with 1.0 than 1.1. I obtain the following results with FreeRDP 1.0. PERSISTENT BLUE SCREEN (bug) Wrong username Wrong password Wrong IP Wrong extra options ERROR (proper behavior) Wrong port Unresolvable hostname With FreeRDP 1.1, all unsuccessful attempts cause a persistent blue screen (that is to say, none of the 2 scenarios which krdc handled fine with 1.0 cause error dialogs to be shown). @Filipus Klutiero: Thanks for testing various scenarios. What do you mean with "Wrong IP"? If I enter an invalid IP or an IP which does not resolve to an RDP server, I get proper messages with 1.0. Implementation note for fixing things: we probably want to connect to the "finished(int, QProcess::ExitStatus)" signal. This is fired when xfreerdp exits. Then we can handle it if no other error message has been shown before. Urs, I cannot remember how I performed the test, but I think you should ignore it. I just retried and I also get an error ("Connection attempt to host failed"), whether I try:
IP of host without RDP server
IP without host
Invalid IP
Sorry
Bug 327476 is another example of a blue screen with no error messages. This bug report has reported more than one issues, it would result in hard to close the report. For the interface which confusing user issue is gone, I can't see any "connect" button on the interface, instead there is a "disconnect" button on the toolbar, it's only clickable when connected to an remote desktop. So, I think there is no such issue now. For bluescreen issue, there is a fix for rdp protocol in Bug 327476 I didn't try if vnc has this issue, too, if yes, I would suggest to file a new bug for it. I think this bug could be closed, if you encountered any issue described in this bug, file new bugs, one for one issue. This appears to be fixed. When attempting to connect via rdp or vnc to a host that doesn't exist the blue screen flashes up but is then closed. VNC displays a message but RDP just closes. Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks. As for any other issues reported here, please file a separate bug report if one doesn't already exist, thank you. Thank you Justin I unfortunately no longer use KDE, RDP or VNC, and I am afraid I am no longer in a position to drive this further. Please report remaining issues individually, see comment 9 for more information. Christoph, why do you think this issue is not a bug? Philippe, please read comment 9 for the reasons. Christoph, even if "there is no issue now" (meaning current versions are not affected by the problem), the broken versions were and remain buggy. "NOT A BUG" is not meant for issues which have been solved. The solution is NOT A BUG because it doesn't describe a single bug, but multiple issues. Could you please file individual tickets for each issue that is still appearing? (In reply to Christoph Feck from comment #16) > The solution is NOT A BUG because it doesn't describe a single bug, but > multiple issues. "NOT A BUG" is not meant for reports about multiple bugs; it is intended for tickets which do not report any bug. > Could you please file individual tickets for each issue that is still > appearing? As I wrote recently, I gave up on KDE. I have not experienced this behavior in the last years and no longer have access to any Debian install close to the one on which I reported this. I also do not use VNC nor have access to any VNC server, and I do not use RDP with any server to which I could connect using KRDC. Therefore, it would be a lot less convenient for me to keep driving this, and I lack the motivation to do this voluntarily. It would be best for those still experiencing to try reporting more focused issues if they feel qualified to decompose the misbehaviour into the responsible technical problems. Or - failing that - to at least confirm that part or all of this persists in a [more] current version, over 6 years later. |