Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-11 Thread Amarjeet Singh
Hi Team,

Below is the code which is passing drive name to XRDP Version 0.9.5

File : */src/protocols/rdp/guac_rdpdr/rdpdr_fs_service.c*


>
>
>
>
>
>
>
>
>
>
*static void guac_rdpdr_device_fs_announce_handler(guac_rdpdr_device*
device,wStream* output_stream, int device_id) {/* Filesystem
header */guac_client_log(device->rdpdr->client, GUAC_LOG_INFO, "Sending
filesystem");Stream_Write_UINT32(output_stream,
RDPDR_DTYP_FILESYSTEM);Stream_Write_UINT32(output_stream, device_id);
  Stream_Write(output_stream, "GUAC\0\0\0\0", 8); /* DOS name *//*
Filesystem data */Stream_Write_UINT32(output_stream,
GUAC_FILESYSTEM_NAME_LENGTH);Stream_Write(output_stream,
GUAC_FILESYSTEM_NAME, GUAC_FILESYSTEM_NAME_LENGTH);}*
*@Nick, If i change it to "Cloud\0\0\0" It is sending Cloud .*


*Thanks and Regards,*
*Amarjeet Singh*

On Sat, Mar 10, 2018 at 10:45 PM, Amarjeet Singh 
wrote:

> @Nick,
>
> Any idea  what parameter is sending to XRDP 0.9.5 as I tried to change
> the  GUAC_OS_TYPE from GUAC to CLOUD which doesn't make any difference.
>
> There might be another parameter which is passing to XRDP 0.9.5 and it
> displaying GUAC as a folder name .
>
>
> Regards,
> Amarjeet Singh
>
> On Mon, Mar 5, 2018 at 6:17 PM, Amarjeet Singh 
> wrote:
>
>> Hi Nick,
>>
>> In my testing, with my changes for GUACAMOLE-446, it doesn't matter what
>>> I set the name of the drive to in Guacamole, it always shows up as "GUAC"
>>> in the XRDP redirected filesystem directory.  I can't find the exact place
>>> in the guacd code where the PreferredDOSName field gets set, but it looks
>>> like maybe it just uses the GUAC_OS_TYPE define from rdpdr_messages.h:
>>> https://github.com/apache/guacamole-server/blob/bc5b01d4d8ab
>>> 0c3c89a08007316d33012261f6b3/src/protocols/rdp/guac_rdpdr/rd
>>> pdr_messages.h#L71
>>
>>
>> I tried to change the GUAC_OS_TYPE from "GUAC" to "CLOUD"  but still it
>> is displaying the name GUAC in xrdp version *0.9.5*
>>
>> *Regards,*
>> *Amarjeet Singh*
>>
>> On Sun, Mar 4, 2018 at 8:20 AM, Nick Couchman  wrote:
>>
>>> On Sat, Mar 3, 2018 at 9:23 AM, Amarjeet Singh 
>>> wrote:
>>>
 I have tested with xrdp version 0.9.5 and got the following :-

 Display name is *"GUAC*" as you have mentioned above.

 View the screenshot : https://www.dropbox.com/s/bp
 sz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0


>>> I suspect the 0.5.0 version you were using from Ubuntu was patched to
>>> include the filesystem name/label functionality rather than just using the
>>> PreferredDosName.
>>>
>>> -Nick
>>>
>>
>>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-10 Thread Amarjeet Singh
@Nick,

Any idea  what parameter is sending to XRDP 0.9.5 as I tried to change
the  GUAC_OS_TYPE
from GUAC to CLOUD which doesn't make any difference.

There might be another parameter which is passing to XRDP 0.9.5 and it
displaying GUAC as a folder name .


Regards,
Amarjeet Singh

On Mon, Mar 5, 2018 at 6:17 PM, Amarjeet Singh  wrote:

> Hi Nick,
>
> In my testing, with my changes for GUACAMOLE-446, it doesn't matter what I
>> set the name of the drive to in Guacamole, it always shows up as "GUAC" in
>> the XRDP redirected filesystem directory.  I can't find the exact place in
>> the guacd code where the PreferredDOSName field gets set, but it looks like
>> maybe it just uses the GUAC_OS_TYPE define from rdpdr_messages.h:
>> https://github.com/apache/guacamole-server/blob/bc5b01d4d8ab
>> 0c3c89a08007316d33012261f6b3/src/protocols/rdp/guac_rdpdr/rd
>> pdr_messages.h#L71
>
>
> I tried to change the GUAC_OS_TYPE from "GUAC" to "CLOUD"  but still it is
> displaying the name GUAC in xrdp version *0.9.5*
>
> *Regards,*
> *Amarjeet Singh*
>
> On Sun, Mar 4, 2018 at 8:20 AM, Nick Couchman  wrote:
>
>> On Sat, Mar 3, 2018 at 9:23 AM, Amarjeet Singh 
>> wrote:
>>
>>> I have tested with xrdp version 0.9.5 and got the following :-
>>>
>>> Display name is *"GUAC*" as you have mentioned above.
>>>
>>> View the screenshot : https://www.dropbox.com/s/bp
>>> sz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0
>>>
>>>
>> I suspect the 0.5.0 version you were using from Ubuntu was patched to
>> include the filesystem name/label functionality rather than just using the
>> PreferredDosName.
>>
>> -Nick
>>
>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-05 Thread Amarjeet Singh
Hi Nick,

In my testing, with my changes for GUACAMOLE-446, it doesn't matter what I
> set the name of the drive to in Guacamole, it always shows up as "GUAC" in
> the XRDP redirected filesystem directory.  I can't find the exact place in
> the guacd code where the PreferredDOSName field gets set, but it looks like
> maybe it just uses the GUAC_OS_TYPE define from rdpdr_messages.h:
> https://github.com/apache/guacamole-server/blob/bc5b01d4d8ab
> 0c3c89a08007316d33012261f6b3/src/protocols/rdp/guac_rdpdr/
> rdpdr_messages.h#L71


I tried to change the GUAC_OS_TYPE from "GUAC" to "CLOUD"  but still it is
displaying the name GUAC in xrdp version *0.9.5*

*Regards,*
*Amarjeet Singh*

On Sun, Mar 4, 2018 at 8:20 AM, Nick Couchman  wrote:

> On Sat, Mar 3, 2018 at 9:23 AM, Amarjeet Singh 
> wrote:
>
>> I have tested with xrdp version 0.9.5 and got the following :-
>>
>> Display name is *"GUAC*" as you have mentioned above.
>>
>> View the screenshot : https://www.dropbox.com/s/bp
>> sz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0
>>
>>
> I suspect the 0.5.0 version you were using from Ubuntu was patched to
> include the filesystem name/label functionality rather than just using the
> PreferredDosName.
>
> -Nick
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Nick Couchman
On Sat, Mar 3, 2018 at 9:23 AM, Amarjeet Singh  wrote:

> I have tested with xrdp version 0.9.5 and got the following :-
>
> Display name is *"GUAC*" as you have mentioned above.
>
> View the screenshot : https://www.dropbox.com/s/
> bpsz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0
>
>
I suspect the 0.5.0 version you were using from Ubuntu was patched to
include the filesystem name/label functionality rather than just using the
PreferredDosName.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
I have tested with xrdp version 0.9.5 and got the following :-

Display name is *"GUAC*" as you have mentioned above.

View the screenshot :
https://www.dropbox.com/s/bpsz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0

Regards,
Amarjeet Singh

On Sat, Mar 3, 2018 at 7:35 PM, Amarjeet Singh  wrote:

> @Nick, Below is the *INFO :-*
>
>
>> What version of XRDP are you using, on what Linux distribution?
>
>
> Linux distribution  : Ubuntu 16.04.3 x64
> XRDP version : xrdp 0.5
>
>
>
>> Also, could you test with an un-modified version of Guacamole and see if
>> the behavior is consistent?
>
> Maybe you could try with a more modern version of XRDP?
>
>
> I will test and update you the same.
>
>
>
> On Sat, Mar 3, 2018 at 7:21 PM, Nick Couchman  wrote:
>
>> On Sat, Mar 3, 2018 at 8:47 AM, Amarjeet Singh 
>> wrote:
>>
>>> @Nick xrdp Version is 0.5.0
>>>
>>>
>> Oh, my.  That is quite old.  Current version of XRDP is 0.9.5, and that
>> is available at least in the EPEL repository for RH/CentOS 7 (EL7), and I
>> would be surprised if it isn't available for other distributions.  Maybe
>> you could try with a more modern version of XRDP?
>>
>> -Nick
>>
>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
 @Nick, Below is the *INFO :-*


> What version of XRDP are you using, on what Linux distribution?


Linux distribution  : Ubuntu 16.04.3 x64
XRDP version : xrdp 0.5



> Also, could you test with an un-modified version of Guacamole and see if
> the behavior is consistent?

Maybe you could try with a more modern version of XRDP?


I will test and update you the same.



On Sat, Mar 3, 2018 at 7:21 PM, Nick Couchman  wrote:

> On Sat, Mar 3, 2018 at 8:47 AM, Amarjeet Singh 
> wrote:
>
>> @Nick xrdp Version is 0.5.0
>>
>>
> Oh, my.  That is quite old.  Current version of XRDP is 0.9.5, and that is
> available at least in the EPEL repository for RH/CentOS 7 (EL7), and I
> would be surprised if it isn't available for other distributions.  Maybe
> you could try with a more modern version of XRDP?
>
> -Nick
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Nick Couchman
On Sat, Mar 3, 2018 at 8:47 AM, Amarjeet Singh  wrote:

> @Nick xrdp Version is 0.5.0
>
>
Oh, my.  That is quite old.  Current version of XRDP is 0.9.5, and that is
available at least in the EPEL repository for RH/CentOS 7 (EL7), and I
would be surprised if it isn't available for other distributions.  Maybe
you could try with a more modern version of XRDP?

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Nick Couchman
On Sat, Mar 3, 2018 at 8:48 AM, Nick Couchman 
wrote:

> On Sat, Mar 3, 2018 at 8:22 AM, Amarjeet Singh 
> wrote:
>
>> I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
>> which is not accessible.
>>
>> Link to view the screenshot :-  https://www.dropbox.com/s/
>>> t2emg56wxg0nito/linux_folders.PNG?dl=0
>>
>>
>>
>> Below is the error I got while opening the folder :- Refer the screenshot
>>
>>>
>>> Link to view the  screenshot :   https://www.dropbox.com/s/w11
>>> d1hj81gwazvs/error_linux.png?dl=0
>>
>>
>>
>
What version of XRDP are you using, on what Linux distribution?

Also, could you test with an un-modified version of Guacamole and see if
the behavior is consistent?

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Nick Couchman
On Sat, Mar 3, 2018 at 8:22 AM, Amarjeet Singh  wrote:

> I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
> which is not accessible.
>
> Link to view the screenshot :-  https://www.dropbox.com/s/
>> t2emg56wxg0nito/linux_folders.PNG?dl=0
>
>
>
> Below is the error I got while opening the folder :- Refer the screenshot
>
>>
>> Link to view the  screenshot :   https://www.dropbox.com/s/
>> w11d1hj81gwazvs/error_linux.png?dl=0
>
>
>
I suspect these are specific to XRDP and how it behaves.  It could also be
the spaces in the folder names that it doesn't like - Linux hasn't always
been as friendly with spaces in folder names as it is, now, and sometimes
that still comes back to haunt us.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
@Nick xrdp Version is 0.5.0

On Sat, Mar 3, 2018 at 7:08 PM, Nick Couchman  wrote:

>
>>>
>>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>>> either the client name, nor the the filesystem name for presenting this
>>> share.
>>
>>
>> I am seeing the same . Please view the screenshots.
>>
>
> Interesting.  Perhaps the version of XRDP you are using has been patched
> to support it.  The Github source code I looked at and the version I used
> (EPEL 7 repo) did not behave this way.  In any case, this is dependent on
> XRDP and how it behaves, and not Guacamole.  Whatever version you are using
> is clearly okay with the lack of UTF-16 encoding, so it looks like they
> have implemented it in a way consistent with other RDP clients and servers.
>
> -Nick
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Nick Couchman
>
>
>>
>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>> either the client name, nor the the filesystem name for presenting this
>> share.
>
>
> I am seeing the same . Please view the screenshots.
>

Interesting.  Perhaps the version of XRDP you are using has been patched to
support it.  The Github source code I looked at and the version I used
(EPEL 7 repo) did not behave this way.  In any case, this is dependent on
XRDP and how it behaves, and not Guacamole.  Whatever version you are using
is clearly okay with the lack of UTF-16 encoding, so it looks like they
have implemented it in a way consistent with other RDP clients and servers.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
One more INFO I would like to share which is as follows :-

*Link target of that folder* : home/gk/.rdp_drive/CLOUD  { gk  is username
}

On Sat, Mar 3, 2018 at 6:52 PM, Amarjeet Singh  wrote:

> I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
> which is not accessible.
>
> Link to view the screenshot :-  https://www.dropbox.com/s/
>> t2emg56wxg0nito/linux_folders.PNG?dl=0
>
>
>
> Below is the error I got while opening the folder :- Refer the screenshot
>
>>
>> Link to view the  screenshot :   https://www.dropbox.com/s/
>> w11d1hj81gwazvs/error_linux.png?dl=0
>
>
>
> I have no idea about it.
>
> Regards,
> Amarjeet Singh
>
>
>
>
>
> On Sat, Mar 3, 2018 at 6:42 PM, Amarjeet Singh 
> wrote:
>
>> Thanks Nick,
>>
>>
>> Below is the link to view the screenshot :-
>>
>> Windows  :   https://www.dropbox.com/s/97m3x94vewi4q2j/windows_device_
>> redirection.PNG?dl=0
>>
>> Linux : https://www.dropbox.com/s/x7mego94nduosbz/liux_device_redi
>> rection.PNG?dl=0
>>
>>>
>>> While the string apparently does not need to be UTF-16 encoded, it does
>>> need to be null-terminated, which you're missing, here.
>>
>>
>>
>> I will fix it.
>>
>>
>>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>>> either the client name, nor the the filesystem name for presenting this
>>> share.
>>
>>
>> I am seeing the same . Please view the screenshots.
>>
>>
>> Regards,
>> Amarjeet Singh
>>
>>
>> On Sat, Mar 3, 2018 at 6:31 PM, Nick Couchman  wrote:
>>
>>> On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh 
>>> wrote:
>>>
 Hi Team,

 I have done the following changes to fix the above issue which works
 both in *Windows  *as well as *Linux RDP.*


>
> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   12*



 *Instead of using above configurations I have used the following  (
 No   UTF-16 encoding  is required  ) :-   *


> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   5*




>>> While the string apparently does not need to be UTF-16 encoded, it does
>>> need to be null-terminated, which you're missing, here.
>>>
>>>
 *and I have used   UTF-16 encoding in the following :-*


 * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*

 *to *

 #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
 \0S\0t\0o\0r\0a\0g\0e\0\0\0"
 #define GUAC_DRIVE_NAME_LENGTH   28

 and used the above in the  *guac_rdpdr_send_client_name_request
 function .*

>>>
>>> Note that the drive name and client name are *not* the same thing.  The
>>> client name is used for redirection, but is used in a broader sense to
>>> identify the client connecting to the server.  I don't know off the top of
>>> my head what the encoding should be for that, but probably UTF-16.
>>>
>>> Your screenshots did not come through, but the storage should show up as
>>>  on , so, in your case, you should see
>>> "Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
>>> this, as XRDP does not look at either the client name, nor the the
>>> filesystem name for presenting this share.  Instead, there's a value
>>> determine on the XRDP side, either in the code or in a configuration file,
>>> for the name of the share, and then it uses the PreferredDosName setting
>>> for the folder name.  None of the changes you have done (nor the ones I
>>> have done in the pull request for the JIRA issue) will impact the way XRDP
>>> sees it, and this is not because of Guacamole, this is because of how the
>>> XRDP code handles it.
>>>
>>> -Nick
>>>
>>
>>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
which is not accessible.

Link to view the screenshot :-
> https://www.dropbox.com/s/t2emg56wxg0nito/linux_folders.PNG?dl=0



Below is the error I got while opening the folder :- Refer the screenshot

>
> Link to view the  screenshot :
> https://www.dropbox.com/s/w11d1hj81gwazvs/error_linux.png?dl=0



I have no idea about it.

Regards,
Amarjeet Singh





On Sat, Mar 3, 2018 at 6:42 PM, Amarjeet Singh  wrote:

> Thanks Nick,
>
>
> Below is the link to view the screenshot :-
>
> Windows  :   https://www.dropbox.com/s/97m3x94vewi4q2j/windows_
> device_redirection.PNG?dl=0
>
> Linux : https://www.dropbox.com/s/x7mego94nduosbz/liux_device_
> redirection.PNG?dl=0
>
>>
>> While the string apparently does not need to be UTF-16 encoded, it does
>> need to be null-terminated, which you're missing, here.
>
>
>
> I will fix it.
>
>
>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>> either the client name, nor the the filesystem name for presenting this
>> share.
>
>
> I am seeing the same . Please view the screenshots.
>
>
> Regards,
> Amarjeet Singh
>
>
> On Sat, Mar 3, 2018 at 6:31 PM, Nick Couchman  wrote:
>
>> On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh 
>> wrote:
>>
>>> Hi Team,
>>>
>>> I have done the following changes to fix the above issue which works
>>> both in *Windows  *as well as *Linux RDP.*
>>>
>>>

 *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
 GUAC_FILESYSTEM_NAME_LENGTH   12*
>>>
>>>
>>>
>>> *Instead of using above configurations I have used the following  (  No
>>>  UTF-16 encoding  is required  ) :-   *
>>>
>>>
 *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
 GUAC_FILESYSTEM_NAME_LENGTH   5*
>>>
>>>
>>>
>>>
>> While the string apparently does not need to be UTF-16 encoded, it does
>> need to be null-terminated, which you're missing, here.
>>
>>
>>> *and I have used   UTF-16 encoding in the following :-*
>>>
>>>
>>> * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*
>>>
>>> *to *
>>>
>>> #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
>>> \0S\0t\0o\0r\0a\0g\0e\0\0\0"
>>> #define GUAC_DRIVE_NAME_LENGTH   28
>>>
>>> and used the above in the  *guac_rdpdr_send_client_name_request
>>> function .*
>>>
>>
>> Note that the drive name and client name are *not* the same thing.  The
>> client name is used for redirection, but is used in a broader sense to
>> identify the client connecting to the server.  I don't know off the top of
>> my head what the encoding should be for that, but probably UTF-16.
>>
>> Your screenshots did not come through, but the storage should show up as
>>  on , so, in your case, you should see
>> "Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
>> this, as XRDP does not look at either the client name, nor the the
>> filesystem name for presenting this share.  Instead, there's a value
>> determine on the XRDP side, either in the code or in a configuration file,
>> for the name of the share, and then it uses the PreferredDosName setting
>> for the folder name.  None of the changes you have done (nor the ones I
>> have done in the pull request for the JIRA issue) will impact the way XRDP
>> sees it, and this is not because of Guacamole, this is because of how the
>> XRDP code handles it.
>>
>> -Nick
>>
>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
Thanks Nick,


Below is the link to view the screenshot :-

Windows  :
https://www.dropbox.com/s/97m3x94vewi4q2j/windows_device_redirection.PNG?dl=0

Linux :
https://www.dropbox.com/s/x7mego94nduosbz/liux_device_redirection.PNG?dl=0

>
> While the string apparently does not need to be UTF-16 encoded, it does
> need to be null-terminated, which you're missing, here.



I will fix it.


>   On XRDP on Linux, you will not see this, as XRDP does not look at
> either the client name, nor the the filesystem name for presenting this
> share.


I am seeing the same . Please view the screenshots.


Regards,
Amarjeet Singh


On Sat, Mar 3, 2018 at 6:31 PM, Nick Couchman  wrote:

> On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh 
> wrote:
>
>> Hi Team,
>>
>> I have done the following changes to fix the above issue which works both
>> in *Windows  *as well as *Linux RDP.*
>>
>>
>>>
>>> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
>>> GUAC_FILESYSTEM_NAME_LENGTH   12*
>>
>>
>>
>> *Instead of using above configurations I have used the following  (  No
>>  UTF-16 encoding  is required  ) :-   *
>>
>>
>>> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
>>> GUAC_FILESYSTEM_NAME_LENGTH   5*
>>
>>
>>
>>
> While the string apparently does not need to be UTF-16 encoded, it does
> need to be null-terminated, which you're missing, here.
>
>
>> *and I have used   UTF-16 encoding in the following :-*
>>
>>
>> * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*
>>
>> *to *
>>
>> #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
>> \0S\0t\0o\0r\0a\0g\0e\0\0\0"
>> #define GUAC_DRIVE_NAME_LENGTH   28
>>
>> and used the above in the  *guac_rdpdr_send_client_name_request function
>> .*
>>
>
> Note that the drive name and client name are *not* the same thing.  The
> client name is used for redirection, but is used in a broader sense to
> identify the client connecting to the server.  I don't know off the top of
> my head what the encoding should be for that, but probably UTF-16.
>
> Your screenshots did not come through, but the storage should show up as
>  on , so, in your case, you should see
> "Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
> this, as XRDP does not look at either the client name, nor the the
> filesystem name for presenting this share.  Instead, there's a value
> determine on the XRDP side, either in the code or in a configuration file,
> for the name of the share, and then it uses the PreferredDosName setting
> for the folder name.  None of the changes you have done (nor the ones I
> have done in the pull request for the JIRA issue) will impact the way XRDP
> sees it, and this is not because of Guacamole, this is because of how the
> XRDP code handles it.
>
> -Nick
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Nick Couchman
On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh  wrote:

> Hi Team,
>
> I have done the following changes to fix the above issue which works both
> in *Windows  *as well as *Linux RDP.*
>
>
>>
>> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
>> GUAC_FILESYSTEM_NAME_LENGTH   12*
>
>
>
> *Instead of using above configurations I have used the following  (  No
>  UTF-16 encoding  is required  ) :-   *
>
>
>> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
>> GUAC_FILESYSTEM_NAME_LENGTH   5*
>
>
>
>
While the string apparently does not need to be UTF-16 encoded, it does
need to be null-terminated, which you're missing, here.


> *and I have used   UTF-16 encoding in the following :-*
>
>
> * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*
>
> *to *
>
> #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
> \0S\0t\0o\0r\0a\0g\0e\0\0\0"
> #define GUAC_DRIVE_NAME_LENGTH   28
>
> and used the above in the  *guac_rdpdr_send_client_name_request function
> .*
>

Note that the drive name and client name are *not* the same thing.  The
client name is used for redirection, but is used in a broader sense to
identify the client connecting to the server.  I don't know off the top of
my head what the encoding should be for that, but probably UTF-16.

Your screenshots did not come through, but the storage should show up as
 on , so, in your case, you should see
"Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
this, as XRDP does not look at either the client name, nor the the
filesystem name for presenting this share.  Instead, there's a value
determine on the XRDP side, either in the code or in a configuration file,
for the name of the share, and then it uses the PreferredDosName setting
for the folder name.  None of the changes you have done (nor the ones I
have done in the pull request for the JIRA issue) will impact the way XRDP
sees it, and this is not because of Guacamole, this is because of how the
XRDP code handles it.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-03-03 Thread Amarjeet Singh
Hi Team,

I have done the following changes to fix the above issue which works both
in *Windows  *as well as *Linux RDP.*


>
> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   12*



*Instead of using above configurations I have used the following  (  No
 UTF-16 encoding  is required  ) :-   *


> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   5*



*and I have used   UTF-16 encoding in the following :-*


* guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*

*to *

#define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
\0S\0t\0o\0r\0a\0g\0e\0\0\0"
#define GUAC_DRIVE_NAME_LENGTH   28

and used the above in the  *guac_rdpdr_send_client_name_request function .*


*Following is the output in the Windows and Linux RDP :- Please refer the
screenshots*









Thanks Nick for the helping me out .

Please look into it and suggest if there is any change required.


Thanks and regards,
Amarjeet Singh

On Mon, Feb 26, 2018 at 8:27 PM, Nick Couchman  wrote:

>
>>
>>> It's interesting that XRDP is still clearly attempting to read things as
>>> UTF-16 here, but if that's failing for unmodified Guacamole, too, then it
>>> must be reading a field which we are not encoding as UTF-16 already (since
>>> the name of Guacamole's filesystem is definitely pre-encoded as UTF-16 at
>>> the moment). Perhaps we're wrong in the handling of whichever value is
>>> being used by XRDP, too?
>>>
>>>
>> I'm going to try to stand up a XRDP test server tomorrow and see if I can
>> test a few things and get some findings consistent with Amarjeet's
>> results.  This point actually puzzles me a little bit, particularly since
>> XRDP apparently works fine with xfreerdp, which does not UTF-16 encode its
>> filesystem name parameter.  Maybe with a few more test cases we can find
>> the illusive pattern.
>>
>> Or we'll just further confuse ourselves ;-).
>>
>> -Nick
>>
>
> It looks to me like xrdp just reads the "PreferredDosName" setting and
> doesn't even bother to try to enumerate the DeviceData:
>
> https://github.com/neutrinolabs/xrdp/blob/5daa09171e1e6e65a1
> a3ab969775fdf8ac37/sesman/chansrv/devredir.c#L691
>
> In my testing, with my changes for GUACAMOLE-446, it doesn't matter what I
> set the name of the drive to in Guacamole, it always shows up as "GUAC" in
> the XRDP redirected filesystem directory.  I can't find the exact place in
> the guacd code where the PreferredDOSName field gets set, but it looks like
> maybe it just uses the GUAC_OS_TYPE define from rdpdr_messages.h:
>
> https://github.com/apache/guacamole-server/blob/bc5b01d4d8ab
> 0c3c89a08007316d33012261f6b3/src/protocols/rdp/guac_rdpdr/
> rdpdr_messages.h#L71
>
> ??  The PreferredDOSName field is supposed to be ASCII, 8 characters, at
> most, and *not* null-terminated...
>
> So, whatever changes get made in -446 should *not* adversely impact XRDP,
> as far as I can tell.  Also, I tested xfreerdp with xrdp, and, when you
> specify a filesytem name longer than 8 characters, it just truncates it at
> 8 ("temporary_files" turned into "temporar").  My guess is that xfreerdp is
> just taking the command line argument for the filesystem name and
> truncating it to 8 characters for the preferred DOS name.
>
> -Nick
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-26 Thread Nick Couchman
>
>
>
>> It's interesting that XRDP is still clearly attempting to read things as
>> UTF-16 here, but if that's failing for unmodified Guacamole, too, then it
>> must be reading a field which we are not encoding as UTF-16 already (since
>> the name of Guacamole's filesystem is definitely pre-encoded as UTF-16 at
>> the moment). Perhaps we're wrong in the handling of whichever value is
>> being used by XRDP, too?
>>
>>
> I'm going to try to stand up a XRDP test server tomorrow and see if I can
> test a few things and get some findings consistent with Amarjeet's
> results.  This point actually puzzles me a little bit, particularly since
> XRDP apparently works fine with xfreerdp, which does not UTF-16 encode its
> filesystem name parameter.  Maybe with a few more test cases we can find
> the illusive pattern.
>
> Or we'll just further confuse ourselves ;-).
>
> -Nick
>

It looks to me like xrdp just reads the "PreferredDosName" setting and
doesn't even bother to try to enumerate the DeviceData:

https://github.com/neutrinolabs/xrdp/blob/5daa09171e1e6e65a1a3ab969775fd
f8ac37/sesman/chansrv/devredir.c#L691

In my testing, with my changes for GUACAMOLE-446, it doesn't matter what I
set the name of the drive to in Guacamole, it always shows up as "GUAC" in
the XRDP redirected filesystem directory.  I can't find the exact place in
the guacd code where the PreferredDOSName field gets set, but it looks like
maybe it just uses the GUAC_OS_TYPE define from rdpdr_messages.h:

https://github.com/apache/guacamole-server/blob/
bc5b01d4d8ab0c3c89a08007316d33012261f6b3/src/protocols/rdp/
guac_rdpdr/rdpdr_messages.h#L71

??  The PreferredDOSName field is supposed to be ASCII, 8 characters, at
most, and *not* null-terminated...

So, whatever changes get made in -446 should *not* adversely impact XRDP,
as far as I can tell.  Also, I tested xfreerdp with xrdp, and, when you
specify a filesytem name longer than 8 characters, it just truncates it at
8 ("temporary_files" turned into "temporar").  My guess is that xfreerdp is
just taking the command line argument for the filesystem name and
truncating it to 8 characters for the preferred DOS name.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-25 Thread Nick Couchman
On Sun, Feb 25, 2018 at 11:05 PM, Mike Jumper 
wrote:

> On Sat, Feb 24, 2018 at 6:03 PM, Nick Couchman  wrote:
>
>>
>>> 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 agree, too, that we need to take the time needed to sort this out -
>> we've already proven, between the three of us, that we can produce varying
>> degrees of success and failure, here, and we need to try to determine some
>> patterns in the expectations.  As I've already mentioned, it looks to me
>> like FreeRDP does not UTF-16 encode this particular field (filesystem
>> name), but I wonder if we can find some other open source RDP
>> implementations that we can use to determine if it's consistently accepted
>> that this should/not be UTF-16 encoded?
>>
>>
> The rdesktop source makes a note on this point:
>
> "The RDP specification says that the DeviceData is supposed to be a
> null-terminated Unicode string, but that does not work. In practice the
> string is expected to be an ASCII string, like a variable-length
> preferredDosName." [1]
>
> Sounds like the spec is just downright wrong for the handling of that
> field. I suppose that's not too much of a surprise - there are numerous
> other fields which are specified in the spec as "ignored", but which
> actually result in mysterious server failures if not set to zero. Assuming
> that above comment is correct, it sounds like we do need to remove use of
> UTF-16 strictly for filesystem names, leaving it in place for the printer?
>

Reminds me of the line from Pirates of the Carribean: "They're not so much
rules, really more guidelines," or something to that effect.

But, yes, I'd agree that it needs to remain in place for the printer, but
(apparently) not for the filesystem name.


>
> It's interesting that XRDP is still clearly attempting to read things as
> UTF-16 here, but if that's failing for unmodified Guacamole, too, then it
> must be reading a field which we are not encoding as UTF-16 already (since
> the name of Guacamole's filesystem is definitely pre-encoded as UTF-16 at
> the moment). Perhaps we're wrong in the handling of whichever value is
> being used by XRDP, too?
>
>
I'm going to try to stand up a XRDP test server tomorrow and see if I can
test a few things and get some findings consistent with Amarjeet's
results.  This point actually puzzles me a little bit, particularly since
XRDP apparently works fine with xfreerdp, which does not UTF-16 encode its
filesystem name parameter.  Maybe with a few more test cases we can find
the illusive pattern.

Or we'll just further confuse ourselves ;-).

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-25 Thread Mike Jumper
On Sat, Feb 24, 2018 at 6:03 PM, Nick Couchman  wrote:

>
>> 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 agree, too, that we need to take the time needed to sort this out -
> we've already proven, between the three of us, that we can produce varying
> degrees of success and failure, here, and we need to try to determine some
> patterns in the expectations.  As I've already mentioned, it looks to me
> like FreeRDP does not UTF-16 encode this particular field (filesystem
> name), but I wonder if we can find some other open source RDP
> implementations that we can use to determine if it's consistently accepted
> that this should/not be UTF-16 encoded?
>
>
The rdesktop source makes a note on this point:

"The RDP specification says that the DeviceData is supposed to be a
null-terminated Unicode string, but that does not work. In practice the
string is expected to be an ASCII string, like a variable-length
preferredDosName." [1]

Sounds like the spec is just downright wrong for the handling of that
field. I suppose that's not too much of a surprise - there are numerous
other fields which are specified in the spec as "ignored", but which
actually result in mysterious server failures if not set to zero. Assuming
that above comment is correct, it sounds like we do need to remove use of
UTF-16 strictly for filesystem names, leaving it in place for the printer?

It's interesting that XRDP is still clearly attempting to read things as
UTF-16 here, but if that's failing for unmodified Guacamole, too, then it
must be reading a field which we are not encoding as UTF-16 already (since
the name of Guacamole's filesystem is definitely pre-encoded as UTF-16 at
the moment). Perhaps we're wrong in the handling of whichever value is
being used by XRDP, too?

- Mike

[1]
https://github.com/rdesktop/rdesktop/blob/a0af72a33712e7c650a57ca32d941ad00abf9589/rdpdr.c#L305-L308


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Nick Couchman
On Sat, Feb 24, 2018 at 2:17 PM, Adam Thorn  wrote:

> On 24/02/2018 14:16, Nick Couchman wrote:
>
> Beyond that, the only other possibility I can think of (outside of the
>> options you've outlined above) is that we should be UTF-16 encoding it,
>> but should using something other than a null terminator for the second
>> byte?  I have no idea if there's any validity to this idea, or if
>> there's anything else you could possibly use besides the null
>> terminator, so this option may be totally unreasonable.
>>
>
> I've not looked at any of the RDP-related code or spec, but one thing I've
> encountered in other MS specifications is that there are places where they
> use UTF-16LE, and are not always as diligent as one might like when it
> comes to specifying byte ordering - so another possibility might be to try
> e.g. "\0G" rather than "G\0" for a suitably encoded "G".
>
> Adam
>
>
Good point - probably worth taking a look at that, too.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Nick Couchman
>
>
> 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 agree, too, that we need to take the time needed to sort this out - we've
already proven, between the three of us, that we can produce varying
degrees of success and failure, here, and we need to try to determine some
patterns in the expectations.  As I've already mentioned, it looks to me
like FreeRDP does not UTF-16 encode this particular field (filesystem
name), but I wonder if we can find some other open source RDP
implementations that we can use to determine if it's consistently accepted
that this should/not be UTF-16 encoded?

Microsoft's documentation clearly is not going to help us...

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Nick Couchman
>
>
>> 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:
>
> * 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.
>
>
So, was reading the spec, and there's definitely some degree of ambiguity
about this.  From the MS-RDPEFS spec [1]:

"...If the client supports DRIVE_CAPABILITY_VERSION_02 in the Drive
Capability Set, then the full name MUST also be specified in the
*DeviceData* field, as a null-terminated Unicode string

. ..."

If you click on the link to "Unicode string" [2], the following definition
is provided:

"*Unicode string*: A Unicode 8-bit string is an ordered sequence of 8-bit
units, a Unicode 16-bit string is an ordered sequence of 16-bit code units,
and a Unicode 32-bit string is an ordered sequence of 32-bit code units. In
some cases, it could be acceptable not to terminate with a terminating null
character. Unless otherwise specified, all Unicode strings
follow
the UTF-16LE encoding scheme with no Byte Order Mark (BOM)."

So, according to Microsoft's documentation, it could either be 8-bit,
16-bit, or 32-bit, and should be 16-bit if not specified, but maybe they
forgot to specify?!  Unfortunately none of their examples actually have any
of that data filled in, so it's hard to know, and they themselves say it's
one of the three.



-Nick

[1] - https://msdn.microsoft.com/en-us/library/cc241357.aspx
[2] -
https://msdn.microsoft.com/en-us/library/cc241307.aspx#gt_b069acb4-e364-453e-ac83-42d469bb339e


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Adam Thorn

On 24/02/2018 14:16, Nick Couchman wrote:


Beyond that, the only other possibility I can think of (outside of the
options you've outlined above) is that we should be UTF-16 encoding it,
but should using something other than a null terminator for the second
byte?  I have no idea if there's any validity to this idea, or if
there's anything else you could possibly use besides the null
terminator, so this option may be totally unreasonable.


I've not looked at any of the RDP-related code or spec, but one thing 
I've encountered in other MS specifications is that there are places 
where they use UTF-16LE, and are not always as diligent as one might 
like when it comes to specifying byte ordering - so another possibility 
might be to try e.g. "\0G" rather than "G\0" for a suitably encoded "G".


Adam



Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Nick Couchman
>
> 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.
>

I think this is the most likely option - I'm wondering if the fact that it
is presented as a sort of network filesystems, almost like a CIFS share,
changes the way the RDP server expects that name to be presented.  Clearly
UTF-16 works for everything else, including printer name (in the changes I
was making to allow that to be configured in GUACAMOLE-445, this definitely
had to be UTF-16 encoded, else it would not render the name correctly), so
my guess is that the filesystem name is just a one-off.  This also matches
with my quick audit of the FreeRDP source code - pretty much everything for
redirection was run through the ConvertToUnicode() function, *except* the
filesystem name.


>
> 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.
>
>
Have you had a chance to look at the FreeRDP source code that I called
out?  As far as I can tell, xfreerdp, when passing through filesystems,
does not encode the filesystem name in UTF-16, but I want a second set of
eyes to verify that I'm seeing that correctly??

Beyond that, the only other possibility I can think of (outside of the
options you've outlined above) is that we should be UTF-16 encoding it, but
should using something other than a null terminator for the second byte?  I
have no idea if there's any validity to this idea, or if there's anything
else you could possibly use besides the null terminator, so this option may
be totally unreasonable.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Amarjeet Singh
Hi Mike,


*Cloud Storage* is displaying correctly in Windows but not in Linux.

Without your changes, is the drive name interpreted correctly by the RDP
> server?
>


I will test and confirm the same.


Regards,
Amarjeet Singh

On Sat, Feb 24, 2018 at 3:40 PM, Mike Jumper 
wrote:

> On Feb 24, 2018 01:27, "Amarjeet Singh"  wrote:
>
> 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.
>
>
> Regardless of the intent of your changes, it is clear that the RDP server
> is interpreting a new non-Unicode string as UTF-16. This, combined with the
> fact that the spec does indeed mandate UTF-16 for at least some of these
> values, means these changes must be made with care.
>
> Without your changes, is the drive name interpreted correctly by the RDP
> server?
>
> - Mike
>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Mike Jumper
On Feb 24, 2018 01:27, "Amarjeet Singh"  wrote:

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.


Regardless of the intent of your changes, it is clear that the RDP server
is interpreting a new non-Unicode string as UTF-16. This, combined with the
fact that the spec does indeed mandate UTF-16 for at least some of these
values, means these changes must be made with care.

Without your changes, is the drive name interpreted correctly by the RDP
server?

- Mike


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-24 Thread Amarjeet Singh
>
> 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/
> *
>




On Sat, Feb 24, 2018 at 12:26 PM, Mike Jumper 
wrote:

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


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-23 Thread Mike Jumper
On Fri, Feb 23, 2018 at 7:38 AM, Nick Couchman  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


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-23 Thread Nick Couchman
On Fri, Feb 23, 2018 at 10:38 AM, Nick Couchman  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).
>
>
FWIW - I took the \0 out of the GUACAMOLE_FILESYSTEM_NAME define (left one
at the end) and changed the length to match, compiled, and confirmed that
it works as expected - it shows "Guacamole on Guacamole_RDP" instead of "G
on Guacamole_RDP".

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-23 Thread Nick Couchman
>
>
> 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).

Looking at the FreeRDP source code, I see the following...

- In channels/drive/client/drive_main.c, starting around line 705
(stable-1.1 branch)[1], you see the processing for the name of the drive.
It looks like this just gets adding to a UINT8 stream with no encoding.
- In channels/drive/client/drive_main.c, starting around line 407
(stable-1.1 branch)[2], you see the handling for the label of the
filesystem.  There is definitely a conversion to UTF done, here, using the
ConvertToUnicode() function.

Am I seeing this correctly, or am I missing something, here?  I'm going to
do some testing and see if I can get a configurable drive name passed
through correctly.

Probably the most annoying thing is that this means that printer name and
drive name have to be dealt with separately (as the FreeRDP code does),
because the printer name definitely does have to be UTF-16 encoded.

-Nick

[1] -
https://github.com/FreeRDP/FreeRDP/blob/851f0979d5b0b45a7595cab7ab1dd2d41d4a73d1/channels/drive/client/drive_main.c#L407
[2] -
https://github.com/FreeRDP/FreeRDP/blob/851f0979d5b0b45a7595cab7ab1dd2d41d4a73d1/channels/drive/client/drive_main.c#L706


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-23 Thread Nick Couchman
>
> */***
> * * 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*
>
>
>> *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.*
>
>
>  Where do I have to encode it ?
>
> Is there anything else I have to do along with the above.
>
>
As I understand it, the \0s inserted into the strings above is the UTF16
encoding.  UTF-16 uses 2 bytes per character, so inserting the \0 in
between each character inserts a null value for the second byte.  The only
thing I see different is that I think you need 2 bytes of null characters
at the very end of the string.  So, instead of

"C\0L\0O\0U\0D\0"

you should do:

"C\0L\0O\0U\0D\0\0\0"

And make sure the length accounts for that (12, instead of 10).

Also, I've been looking at GUACAMOLE-445 and 446 for making these
parameters configurable (for both printer name and filesystem), and I'm not
entirely certain that the FILESYSTEM_NAME or FILESYSTEM_LABEL are actually
visible at all to the user - as far as I can tell, the client name sent
with guac_rdpdr_send_client_name_request() is the only thing that ever
shows up for the user (C on ).  Could just be how my Server
2012 system is configured, but that's what I'm seeing.

-Nick


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-22 Thread Amarjeet Singh
Hi Mike,


I appreciate your efforts. I will be more diligent and do more debugging
and testing before reporting any bug on JIRA.

Thanks Mike for helping and guiding me out.

I have done 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*


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


 Where do I have to encode it ?

Is there anything else I have to do along with the above.


Thanks and Regards,
Amarjeet Singh

On Fri, Feb 23, 2018 at 6:35 AM, Mike Jumper 
wrote:

> On Thu, Feb 22, 2018 at 4:35 PM, Mike Jumper 
> wrote:
>
>> ...
>>
>> ... the name of the redirected drive is not correct. ... NOTE : - I have
>>> changed the name of the drive from Guacamole to Cloud Drive in
>>> guacamole-server [ Is it is the reason ? ]
>>>
>>
>> Yes. You have changed the name from a correctly-encoded value to
>> something which is not correctly encoded.
>>
>>
> FYI, regarding your modifications, your screenshot shows the following
> text:
>
> 汃畯瑓牯条e
>
> Breaking that down as Unicode, we get:
>
> U+6C43 = 汃
> U+756F = 畯
> U+7453 = 瑓
> U+726F = 牯
> U+6761 = 条
> U+0065 = e
>
> 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
>
>


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-22 Thread Mike Jumper
On Thu, Feb 22, 2018 at 4:35 PM, Mike Jumper 
wrote:

> ...
>
> ... the name of the redirected drive is not correct. ... NOTE : - I have
>> changed the name of the drive from Guacamole to Cloud Drive in
>> guacamole-server [ Is it is the reason ? ]
>>
>
> Yes. You have changed the name from a correctly-encoded value to something
> which is not correctly encoded.
>
>
FYI, regarding your modifications, your screenshot shows the following text:

汃畯瑓牯条e

Breaking that down as Unicode, we get:

U+6C43 = 汃
U+756F = 畯
U+7453 = 瑓
U+726F = 牯
U+6761 = 条
U+0065 = e

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


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-22 Thread Mike Jumper
On Thu, Feb 22, 2018 at 6:30 AM, Amarjeet Singh 
wrote:

> Hi Mike,
>
>
Amarjeet, please avoid duplicating your threads across multiple locations.
Emailing both JIRA and the user@ list creates both a comment in JIRA and a
new thread on user@.

... the name of the redirected drive is not correct. ... NOTE : - I have
> changed the name of the drive from Guacamole to Cloud Drive in
> guacamole-server [ Is it is the reason ? ]
>

Yes. You have changed the name from a correctly-encoded value to something
which is not correctly encoded.

Amarjeet ... please try to be more diligent. The verification which was
ultimately done on GUACAMOLE-512 (the verification that revealed the
problem was not in Guacamole) is something that should have been done
before the issue was opened in the first place. This goes double if you
have made modifications to the source: if you wish to report a problem with
Guacamole, you need to actually be using Guacamole, not your own modified
software.

- Mike


Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

2018-02-22 Thread Amarjeet Singh
Hi Mike,

You are using *XRDP* as your RDP server on Ubuntu


Yes, I am using XRDP as   RDP server on Ubuntu

Drive redirection works when connecting to this XRDP instance with
> *xfreerdp* from another, separate Linux machine


Yes, Drive redirection works when connecting to this XRDP instance with
xfreerdp from another ( separate ) Linux Machine.




On Thu, Feb 22, 2018 at 2:47 PM, Nick Couchman (JIRA) 
wrote:

>
>  [ https://issues.apache.org/jira/browse/GUACAMOLE-512?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Nick Couchman updated GUACAMOLE-512:
> 
> Priority: Minor  (was: Critical)
>
> > Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
> > ---
> >
> > Key: GUACAMOLE-512
> > URL: https://issues.apache.org/jira/browse/GUACAMOLE-512
> > Project: Guacamole
> >  Issue Type: Bug
> >  Components: guacamole
> >Affects Versions: 0.9.14
> > Environment: Remote Server : Ubuntu
> >Reporter: Amarjeet Singh
> >Priority: Minor
> >
> > Shared drive redirection works with xrdp command line [ O.S. : Ubuntu ]
> but it doesn't work with Guacamole.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>