guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amarjeet Singh <amarjee...@gmail.com>
Subject Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
Date Sat, 24 Feb 2018 09:27:28 GMT
>
> 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.


I have not removed UTF-16. I did the following  changes.

guac_rdpdr_send_client_name_request(rdpdr, "Guacamole RDP");   to
guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");   in
*rdpdr_messages.c*


*and *



*/***
* * Name of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_NAME          "G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0"*
*#define GUAC_FILESYSTEM_NAME_LENGTH   20*

*/***
* * Label of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_LABEL          "G\0U\0A\0C\0F\0I\0L\0E\0"*
*#define GUAC_FILESYSTEM_LABEL_LENGTH   16*



to



*/***
* * Name of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_NAME          "C\0L\0O\0U\0D\0\0\0"*
*#define GUAC_FILESYSTEM_NAME_LENGTH   12*

*/***
* * Label of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_LABEL          "C\0L\0O\0U\0D\0"*
*#define GUAC_FILESYSTEM_LABEL_LENGTH   10*


I haven't removed UTF-16 encoding. I changed letters of GUACAMOLE to CLOUD
and changed the Length.
If I replace the name of the *GUAC_FILESYSTEM_NAME *with CLOUD, it changes
the name of the Shared drive from *G on* to *C on* in Windows and Linux*.*

It means that Windows does not add G on or C on by itself*. It is
configurable as said by Nick as well.*


*I also went through the following link to make changes.*


> *https://sourceforge.net/p/guacamole/discussion/1110834/thread/84e0b9c6/
> <https://sourceforge.net/p/guacamole/discussion/1110834/thread/84e0b9c6/>*
>




On Sat, Feb 24, 2018 at 12:26 PM, Mike Jumper <mike.jumper@guac-dev.org>
wrote:

> 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
>
>

Mime
View raw message