Bug 7033 - tl-run-rdesktop should handle more disconnect reason codes
Summary: tl-run-rdesktop should handle more disconnect reason codes
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Misc (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.9.0
Assignee: Samuel Mannehed
Keywords: prosaic, thomas_tester
Depends on:
Blocks: 6096
  Show dependency treegraph
Reported: 2017-09-05 10:38 CEST by Henrik Andersson
Modified: 2017-12-07 15:30 CET (History)
3 users (show)

See Also:
Acceptance Criteria:


Description Henrik Andersson cendio 2017-09-05 10:38:55 CEST
There is 35 different disconnect reason codes that have a good explaination of why one get disconnected from a RDP session. tl-run-rdesktop handles 7 of them and reports back via dialog to end user the specific reason for the disconnect. However, if not handled, a generic disconnect message and the code (number) is presented, which is a bit simple. There is definitely more codes that would be valued if presented as text instead of a number, such as code 5: "The connection to the session was replaced by another client".
Comment 3 Samuel Mannehed cendio 2017-10-02 15:05:48 CEST
The initial description is a bit wrong. The 7 codes that are handled by tl-run-rdesktop are cases where we decided to not show any error at all. Unfortunately, code comments explaining this was removed in r28403 for bug 4352.

However, there is still a point in that there are some return codes that could be presented to the user instead of either ignoring them (as explained above) or being handled by the generic message that displays the exit code number.
Comment 4 Samuel Mannehed cendio 2017-10-02 15:06:38 CEST
Official documentation for the codes from the RDP server:

Comment 6 Samuel Mannehed cendio 2017-10-02 15:41:45 CEST
Should be improved now.

Testing should most importantly verify that we are not getting any error messages when the user disconnects or logs out himself. Other normal disconnection cases should also be verified.

Needs to be tested against at least Windows Server 2008 R2 and Windows Server 2012. I have tested 2016 quite extensively.
Comment 9 Samuel Mannehed cendio 2017-10-03 15:18:23 CEST
Some of the messages were modified to be more end user friendly after internal feedback. A few new specific messages were added as well.
Comment 10 Samuel Mannehed cendio 2017-10-03 18:50:17 CEST
I did not manage to trigger all return codes from rdesktop. For example the out_of_memory one got interesting;

I found a tool made by microsoft that was made for testing low-memory conditions. When I finally reached a point where my VMWare machine didn't allow me to create a remote session I got a protocol error from rdesktop instead.

However, it's not crucial to trigger all of the cases for testing here since they all use the same mechanism. The most important parts are that we catch and help out in the most common cases and doesn't display a confusing message.
Comment 11 Thomas Nilefalk cendio 2017-10-04 15:06:13 CEST
Verified message for "logged in from elsewhere" using tlclient second session, verified messages for disconnect & log off (and send message and shadow) from local Server Manager, all ok.

Would suggest changing message for log-off to "An administrator logged you out from you remote desktop session."
Comment 13 Samuel Mannehed cendio 2017-10-09 16:09:09 CEST
The tests mentioned in Comment #11 was carried out on 2012 R2.

Note that testing for Windows server 2008 R2 remains.
Comment 14 Thomas Nilefalk cendio 2017-10-10 10:45:49 CEST
Ran the same tests on 2008 (the demo system) with all three messages showing up ok.
Comment 15 Samuel Mannehed cendio 2017-12-06 17:08:06 CET
There seems to be an issue for some sessions that were redirected by the broker. In such a session, when the administrator uses the Server Manager to log the user out, no message was displayed to the user, and the log said that the user himself disconnected.

The reason sent by the server was:


Which is the same reason the server sends as when the user disconnects himself.

In a session which wasn't redirected by the broker, the same procedure results in the correct behavior by tl-run-rdesktop (a message dialogue and the correct log message).
Comment 16 Samuel Mannehed cendio 2017-12-07 15:29:54 CET
Our initial plan was to try to reproduce this behavior with Microsoft's client, but we hit some roadblocks.

The fact is that we have verified that the RDS server sends the same reason code for these two actions (normal user disconnect and admin log out after broker redirect). It is difficult to handle this perfectly:

 * Normal user disconnect is very common and should not show any message to the user.
 * An administrator logging the user out after the connection has been redirected by the broker should be less common but should ideally show a message to the user since it could be unexpected.

However, we have decided to not care about this behavior. It is likely a bug in Microsoft's RDS server.

Notes about what happened when trying to reproduce with mstc:

We were not able to successfully connect using mstc when the broker wanted to redirect the connection to another server due to  issues with how our connection broker is setup. Microsoft's client expects the user to connect using a DNS-name that corresponds to the RDS collection, and not directly to one of the hosts. rdesktop doesn't care about this.

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