Bugzilla – Bug 7033
tl-run-rdesktop should handle more disconnect reason codes
Last modified: 2017-12-07 15:30:10
You need to
before you can comment on or make changes to this bug.
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".
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
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.
Official documentation for the codes from the RDP server:
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.
Some of the messages were modified to be more end user friendly after internal
feedback. A few new specific messages were added as well.
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.
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."
The tests mentioned in Comment #11 was carried out on 2012 R2.
Note that testing for Windows server 2008 R2 remains.
Ran the same tests on 2008 (the demo system) with all three messages showing up
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
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
* 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.