On Fri, Feb 23, 2018 at 7:38 AM, Nick Couchman <vnick@apache.org> wrote:

The UTF-16 equivalent for this in the byte order used by RDP would be:

    43 6C 6F 75 53 74 6F 72 61 67 65 00

Which is the equivalent of the string:

    "ClouStorage"

So you have apparently changed the UTF-16 string ("G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0") to something which is not encoded in UTF-16 ("ClouStorage"). Because RDP requires this to be UTF-16, it interprets it as such.

- Mike


Mike,
I'm playing with configuring the drive name and looking at the FreeRDP source code, and I'm not sure that the actual name is supposed to be UTF-16 encoded.

If I use xfreerdp to connect to a system I can specify the following flag:
/drive:tmp:/tmp

When I connect to the system, I see a drive in the Computer called "tmp on linux-host" - which means it isn't passing through a drive letter, it's passing through a filesystem name.  What I suspect is happening is that this filesystem name is *not* supposed to be UTF-16 encoded and when you pass the UTF-16 encoded string that begins with either "G\0" (for "Guacamole", as is the default) or "C\0" (for "Cloud Storage", as Amarjeet is using), it takes the first character, stops at the null terminator, and then just uses that first character and calls it either "G on Guacamole RDP" or "C on Guacamole RDP" - which, because it's a single capital letter, makes it look like a drive letter, when it's actually technically a share name (\\tsclient\C or \\tsclient\G or \\tsclient\tmp).


The spec does call for UTF-16, but you present an interesting and plausible theory. If specifying non-UTF-16 does work, then one of the following must be true:

* The RDP server is detecting that we are (incorrectly) sending non-UTF-16 and adjusting accordingly. Given the number of undocumented assumptions I've encountered in the past while working with RDP (where the RDP server will outright fail if some undocumented field is not set to a specific value), this seems unlikely.

* We are not setting some flag correctly, and the part of the specification which requires UTF-16 for that field is not taking effect, instead falling back to an older, non-Unicode version.

* The RDP spec is wrong and UTF-16 is not used here.

* UTF-16 should indeed be used, but not across the board in the case of the drive, and we are erroneously using UTF-16 in some of the cases where it is not allowed.

It is, however, *definitely* part of the spec. Accidental or not, Amarjeet has effectively demonstrated through his changes that removing UTF-16 entirely will cause problems. We need to tread very carefully here.

- Mike