guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <>
Subject Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
Date Mon, 26 Feb 2018 04:13:51 GMT
On Sun, Feb 25, 2018 at 11:05 PM, 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?

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 ;-).


View raw message