On Fri, Feb 23, 2018 at 7:38 AM, Nick Couchman <vn...@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
