contents of an USB drive connected to the terminal cannot be listed

[jt-fuw]

xrdp version

0.9.17

Detailed xrdp version, build options

Paste the result between `~~~`.  Please DO NOT remove `~~~`!
$ xrdp --version
xrdp 0.9.17
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2020 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --enable-ipv6
      --enable-jpeg
      --enable-fuse
      --enable-rfxcodec
      --enable-opus
      --enable-painter
      --enable-vsock
      --build=x86_64-linux-gnu
      --prefix=/usr
      --includedir=${prefix}/include
      --mandir=${prefix}/share/man
      --infodir=${prefix}/share/info
      --sysconfdir=/etc
      --localstatedir=/var
      --disable-silent-rules
      --libdir=${prefix}/lib/x86_64-linux-gnu
      --libexecdir=${prefix}/lib/x86_64-linux-gnu
      --disable-maintainer-mode
      --disable-dependency-tracking
      --with-socketdir=/run/xrdp/sockdir
      build_alias=x86_64-linux-gnu
      CFLAGS=-g -O2 -ffile-prefix-map=/build/xrdp-asBei3/xrdp-0.9.17=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
      LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now -Wl,--as-needed
      CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 -Wno-error=deprecated-declarations
      PKG_CONFIG_PATH=/build/xrdp-asBei3/xrdp-0.9.17/pkgconfig

  Compiled with OpenSSL 3.0.2 15 Mar 2022

Operating system & version

Ubuntu 22.04.5 LTS

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

xorgxrdp 1:0.2.17-1build1 (there is also Xvnc)

What desktop environment do you use?

LXQt configured to look as LXDE

Environment xrdp running on

physical

What's your client?

Dell Wyse 3020, ThinOS 8.8_024, BIOS 7.1_216, Citrix Reveiver 14.051952

Area(s) with issue?

File transfer / drive redirection

Steps to reproduce

Put an USB pendrive into terminal's USB port, connect to the host; or connect at first, then put the pendrive... result is the same, although need wait several seconds after putting the pendrive in for it to be noticed by the host OS - it is shown as 'D' subdirectory in "$HOME/thinclient_drives". Then, invoke File Manager to access the drive, or "ls ~/thinclient_drives/D" - it is shown as empty.

✔️ Expected Behavior

File Manager and 'ls' command to show files and directories on the drive.

❌ Actual Behavior

The drive is shown as empty; an attempt to create a directory fails if an existent name is specified (and an error message tells it exists), succeeds when the name is new and correct; files can be copied to the drive and to a directory on it (providing user knows the directory name); but no result can be seen, still nothing is shown. When the pendrive is later put in a computer, it contains these copied files, created directories... When an exact drive object name is known, 'ls' can show it, 'cp' can copy... the only that fails is directory search ('ls' with wildcard name, or 'ls' without -d with dir name), which always tells that nothing exists. An "ls -d $HOME/thinclient_drives/D" shows it, same for subdirectories; 'stat' shows object when non-wildcard name is specified.

The same terminal and the same pendrive were tried with MS Windows XP, and 'dir' worked fine, showing the pendrive dir contents. xrdp-bug.zip

Anything else?

I remember Novell NetWare required escaping wildcards in names for searches... is it possible that RDP needs sth similar?

I included logs and some .ini files from /etc/xrdp/; there is no xrdp.conf there - the /etc/xrdp/ contains: cert.pem km-00000410.ini km-00000807.ini km-19360409.ini key.pem km-00000411.ini km-00000809.ini pulse/ km-00000406.ini km-00000412.ini km-0000080a.ini reconnectwm.sh km-00000407.ini km-00000414.ini km-0000080c.ini rsakeys.ini km-00000409.ini km-00000415.ini km-00000813.ini sesman.ini km-0000040a.ini km-00000416.ini km-00000816.ini startwm.sh km-0000040b.ini km-00000419.ini km-0000100c.ini xrdp.ini km-0000040c.ini km-0000041d.ini km-00010409.ini xrdp_keyboard.ini

Some workaround I found: put on the pendrive a file of some known name containing list of files there, read the file and access needed files by specifying their names - it works, the only that fails is finding objects on a pendrive. Unfortunately, the ThinOS doesn't provide any user-accessible means to see a pendrive contents - it provides only an interface to use the Wyse 3020 as a terminal, plus diagnose networking problems.

[matt335672]

xrdp v0.9.17 suffers from #327.

Can you check that you only have drive redirections requested in the client?

Failing that, please post the chansrv log which is in $HOME/.local/share/xrdp/xrdp-chansrv.$D.log (`$D is the display number)

[jt-fuw]

Hello, thanks for your mail. I had printer redirection enabled; now I disabled everything except disk redirection, but the behavior is still the same. These redirections can be specified in two places in Connection Manager: one is for global settings, and the other is for per-connection settings, I checked both, and then turned the terminal off and on again, and re-checked. The per-connection settings Local tab contains:

• Auto-connect to local devices: [] Printers []Serials [] USB [] Smart Cards [] Disks (I tried with USB enabled and disabled, no difference; disabling Disks causes the 'D' for pendrive isn't shown)

The log is rather short - a single line: [20241014-21:31:28] [INFO ] Socket 12: AF_UNIX connection received [20241014-21:48:26] [INFO ] Socket 12: AF_UNIX connection received (this is the line from 2 logs)

Can the XRDP be configured to provide some more useful info?

Can some newer version behave better? If yes, where should I download it from, and what version?

With kind regards, Jerzy Tarasiuk, Physics Faculty, University of Warszawa

W dniu 2024-10-14 11:22, matt335672 napisał(a):

xrdp v0.9.17 suffers from #327 [1].

Can you check that you only have drive redirections requested in the client?

Failing that, please post the chansrv log which is in $HOME/.local/share/xrdp/xrdp-chansrv.$D.log (`$D is the display number)

-- Reply to this email directly, view it on GitHub [2], or unsubscribe [3]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/neutrinolabs/xrdp/issues/327 [2] https://github.com/neutrinolabs/xrdp/issues/3268#issuecomment-2410562974 [3] https://github.com/notifications/unsubscribe-auth/ABTFK4O5UYC4SIZXJHOGOR3Z3OEONAVCNFSM6AAAAABPNTCXNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJQGU3DEOJXGQ

[jt-fuw]

Hello again, I downloaded xrdp 9.26 and xorgxrdp 9.20 sources and want to compile them. Can you give me a hint what "configure" options should I use? I suppose e.g. a "--disable-maintainer-mode" used to build Ubuntu's xrdp may be cause of so little messages in xrdp-chansrv.$D.log With kind regards, Jerzy Tarasiuk, Physics Faculty, University of Warszawa

W dniu 2024-10-14 11:22, matt335672 napisał(a):

xrdp v0.9.17 suffers from #327 [1].

Can you check that you only have drive redirections requested in the client?

Failing that, please post the chansrv log which is in $HOME/.local/share/xrdp/xrdp-chansrv.$D.log (`$D is the display number)

[matt335672]

I'll address both of your messages separately.

1) If you look in /etc/xrdp/sesman.ini you'll find a section [ChansrvLogging]. Set the LogLevel to DEBUG and you should get more information from the connection attempt. That said, looking at the source for 0.9.17 suggests to me that this may not be that productive. 2) Looking at your xrdp -v, everything above the --build=x86_64-linux-gnu line should be included. Also, include --enable-devel-all which will give us better logging.

I suggest you try 1) first, but it may not be that helpful.

If you do 2), you'll need to remove the installed xrdp package completely or the two versions may get confused with each other.

Let us know how it goes.

[jt-fuw]

Just setting LogLevel=DEBUG causes the log to contain: [20241015-13:13:29]` [INFO ] Socket 12: AF_UNIX connection received [20241015-13:13:29] [DEBUG] Closed socket 11 (AF_UNIX) [20241015-13:13:29] [DEBUG] clipboard_init st 1, maj 6 min 0 and I doubt it to be helpful.

Then I compiled xrdp with "configure" options: --disable-silent-rules --disable-dependency-tracking --enable-ipv6 --enable-jpeg --enable-fuse --enable-devel-all --enable-opus --enable-vsock --enable-maiintainer-mode --with-socketdir=/run/xrdp/sockdir (strange: I misspelled "maiintainer", but seems it caused no error message, and mainteiner mode was enabled), compiled xorgxrdp without specifying any "configure" options, installed them and started. Now the log is over 100kB long - I tried access to the pendrive, the error was again.

I compiled the "xrdp" again, now with "configure" options: --disable-silent-rules --disable-dependency-tracking --enable-ipv6 --enable-jpeg --enable-fuse --enable-devel-all --enable-opus --enable-vsock --enable-maintainer-mode --with-socketdir=/run/xrdp/sockdir --disable-painter --disable-rfxcodec (the "maintainer" was spelled correctly now), compiled and installed it, and repeated the test again. Seems the log is similar.

Attached: output from the second "configure", xrdp-chansrv.*.log (from both tests). xrdp2024-10-15logs1.zip

[jt-fuw]

Two more logs. xrdp-chansrv.12.log1 - I used a dirname "jt" from the pendrive that I remembered; xrdp-chansrv.12.log2 - I put a list of files and directories of the pendrive in a file "i" that I put on the pendrive (using a computer to get the file list), and I used the list to access some files and directories. xrdp2024-10-15logs2.zip

[jt-fuw]

Yet another log - now session using "rdesktop" from Ubuntu 18.04.5 LTS, with a directory redirected to be seen as a disk on the xrdp host. xrdp2024-10-15logs3.zip

[matt335672]

That's great progress, but I'm having problems deciphering the large number of messages here!

Can we go back to your post here. I'm not sure I fully understand it, and also I don't know what you're seeing in your thin client.

Two more logs. xrdp-chansrv.12.log1 - I used a dirname "jt" from the pendrive that I remembered; xrdp-chansrv.12.log2 - I put a list of files and directories of the pendrive in a file "i" that I put on the pendrive (using a computer to get the file list), and I used the list to access some files and directories.

Let's stick with xrdp-chansrv.12.log1 and the pendrive.

1) Can you give me a list of the contents of the top level of the pendrive? 2) Connect the pendrive to your client and log in to xrdp 3) what do you get for ls -al ~/thinclient_drives ? 4) what do you get for ls -al ~/thinclient_drives/D ? 5) After the above, what does the chansrv log file contain?

Thanks

[jt-fuw]

xrdp2024-10-16a.zip See "info.txt" for info what is in which file.

[matt335672]

Sorry @jt-fuw - I'm having trouble matching up what I asked for with what you have provided. As a result I still don't know exactly what the problem is, or whether there is indeed a problem.

Can you please perform steps 1-5 above exactly as requested?

Thanks.

[jt-fuw]

1. file "p-dir.l" contains "ls" of everything that is on the pendrive. 2-4. file "cmds.log": commands and their output copied from screen. "date" and "ls" on the log file should help to find which parts of the log are results of which command for accessing the pendrive. Note "ls -la" on the pendrive or a subdirectory on it results in error "ls: cannot open directory '(name)': No such file or directory"; later "ls -lad" shows the directory exists (its content cannot be listed). 5. file "xrdp-chansrv.12.log".

(all these files are in xrdp2024-10-16a.zip)

[matt335672]

OK - thanks for that. That's clear now. It's a great way to do it.

I started looking at the command ls -la thinclient_drives/D. According to cmds.log, that is bytes 93965 - 99183 of the chansrv log file. I extracted that with:-

dd if=xrdp-chansrv.12.log bs=1 skip=93965 count=$((99183 - 93965)) of=xrdp-chansrv-skip.log

After removing messages not related to the redirector I got the following:-

1:[20241016-19:33:20] [DEBUG] [xfuse_cb_lookup(chansrv_fuse.c:1635)] looking for parent=1 name=D
2:[20241016-19:33:20] [DEBUG] [xfuse_cb_lookup(chansrv_fuse.c:1653)] found entry for parent=1 name=D
3:[20241016-19:33:21] [DEBUG] [xfuse_cb_opendir(chansrv_fuse.c:2568)] inode=4
4:[20241016-19:33:21] [DEBUG] [xfuse_cb_opendir(chansrv_fuse.c:2597)] did not find entry; redirecting call to devredir
5:[20241016-19:33:21] [DEBUG] [xfuse_cb_opendir(chansrv_fuse.c:2610)] dev_id=19 ino=4 full_path=/D
6:[20241016-19:33:21] [DEBUG] [devredir_irp_with_pathnamelen_new(irp.c:109)] entered
7:[20241016-19:33:21] [DEBUG] [devredir_irp_get_last(irp.c:267)] returning irp=(nil)
8:[20241016-19:33:21] [DEBUG] [devredir_irp_with_pathnamelen_new(irp.c:133)] new IRP=0x79a6b80451b0
9:[20241016-19:33:21] [DEBUG] [devredir_send_drive_create_request(devredir.c:612)] device_id=19 path="\" DesiredAccess=0x100001 CreateDisposition=0x1 FileAttributes=0x0 CreateOptions=0x21 CompletionId=1
10:[20241016-19:33:21] [DEBUG] [devredir_get_dir_listing(devredir.c:1344)] looking for device_id=19 path=\
11:[20241016-19:33:21] [DEBUG] [my_trans_data_in(chansrv.c:913)] my_trans_data_in:
12:[20241016-19:33:21] [DEBUG] [process_message_channel_data(chansrv.c:450)] process_message_channel_data: chan_id 1 chan_flags 3
13:[20241016-19:33:21] [DEBUG] [devredir_irp_find(irp.c:219)] returning irp=0x79a6b80451b0
14:[20241016-19:33:21] [DEBUG] [devredir_proc_device_iocompletion(devredir.c:1072)] got CID_CREATE_DIR_REQ
15:[20241016-19:33:21] [DEBUG] [my_trans_data_in(chansrv.c:913)] my_trans_data_in:
16:[20241016-19:33:21] [DEBUG] [process_message_channel_data(chansrv.c:450)] process_message_channel_data: chan_id 1 chan_flags 3
17:[20241016-19:33:21] [DEBUG] [devredir_irp_find(irp.c:219)] returning irp=0x79a6b80451b0
18:[20241016-19:33:21] [ERROR] [devredir_proc_device_iocompletion(devredir.c:1076)] CompletionType = CID_DIRECTORY_CONTROL, IoStatus=c000000d Pathname = \*
19:[20241016-19:33:21] [DEBUG] [xfuse_devredir_cb_enum_dir_done(chansrv_fuse.c:1068)] fip=0x79a6b8045170 IoStatus=0xc000000d
20:[20241016-19:33:21] [DEBUG] [devredir_send_drive_close_request(devredir.c:688)] sent close request; expect CID_FILE_CLOSE
21:[20241016-19:33:22] [DEBUG] [my_trans_data_in(chansrv.c:913)] my_trans_data_in:
22:[20241016-19:33:22] [DEBUG] [process_message_channel_data(chansrv.c:450)] process_message_channel_data: chan_id 1 chan_flags 3
23:[20241016-19:33:22] [DEBUG] [devredir_irp_find(irp.c:219)] returning irp=0x79a6b80451b0
24:[20241016-19:33:22] [DEBUG] [devredir_proc_device_iocompletion(devredir.c:1072)] got CID_CLOSE
25:[20241016-19:33:22] [DEBUG] [devredir_irp_delete(irp.c:152)] irp=0x79a6b80451b0 completion_id=1 type=7
26:[20241016-19:33:22] [DEBUG] [devredir_irp_dump(irp.c:275)] ------- dumping IRPs --------
27:[20241016-19:33:22] [DEBUG] [devredir_irp_dump(irp.c:278)]         completion_id=1   completion_type=7   FileId=5
28:[20241016-19:33:22] [DEBUG] [devredir_irp_dump(irp.c:283)] ------- dumping IRPs done ---
29:[20241016-19:33:22] [DEBUG] [devredir_irp_dump(irp.c:275)] ------- dumping IRPs --------
30:[20241016-19:33:22] [DEBUG] [devredir_irp_dump(irp.c:283)] ------- dumping IRPs done ---

The important bits here are:-	Lines	Ref
9	Send DR_CREATE_REQ to the client
11-19	Receive DR_CREATE_RSP with an IoStatus of 0xc000000d (STATUS_INVALID_PARAMETER)

The STATUS_INVALID_PARAMETER results in the error on the Linux side.

I'll have to check all the values we're sending from our side to try to figure out what the thin client doesn't like. That might take me a while.I'll try to get some patches put together for you against xrdp v0.9.26.

[jt-fuw]

Try the newest version - xrdp v0.10.1 (2024/07/31) with xorgxrdp v0.10.2 ? This xrdp2024-10-17.zip contains cmds10.log and xrdp-chansrv.12.log for this version - the behavior is still the same, directory contents not shown.

[matt335672]

The redirector hasn't been changed for a while, so that's not surprising.

You mention Windows XP above. Have you tried any more recent versions of Windows with the thin client? I can look into what Windows does for this operation, but I'm not even sure I can get a Windows XP VM working these days!

[jt-fuw]

I tried Windows 10 right now - and I saw contents of the pendrive connected to the terminal (the same thin client terminal, the same pendrive). However, I don't know a way to trace the communication - I suppose it is encrypted.

[matt335672]

Windows 10 is fine - thanks very much.

The encryption is indeed encrypted. My plan is to connect to Windows 10 using FreeRDP, and then instrument the code related to the messages I've mentioned above. I'll then see how DR_CREATE_REQ from Windows differs from the xrdp one.

[matt335672]

I've had a quick look at this, but as it's the weekend I'm stopping here and just documenting what I've found so far. I need to do more deciphering of the output.

I've made this patch to FreeRDP 3.7.0. It's not pretty, but then I'm not a FreeRDP developer!

--- ./channels/drive/client/drive_main.c.orig   2024-08-08 10:38:21.000000000 +0100
+++ ./channels/drive/client/drive_main.c    2024-10-19 16:45:34.584383060 +0100
@@ -191,6 +191,9 @@
    }
    else
    {
+            char lpstr[1024] = { 0 };
+            ConvertWCharToUtf8(file->fullpath, lpstr, ARRAYSIZE(lpstr)); 
+        printf("MJ_CREATE : DesiredAccess:%08x FileAttributes:%08X SharedAccess:%08X CreateDisposition:%08X CreateOptions:%08X File:%s\n", DesiredAccess, FileAttributes, SharedAccess, CreateDisposition, CreateOptions, lpstr);
        void* key = (void*)(size_t)file->id;

        if (!ListDictionary_Add(drive->files, key, file))

I've then connected to a Windows 10 machine using the switch /drive:D,/tmp

Within the remote session, I get up a CMD prompt, and issue the command dir \\tsclient\D. I get the following debug output:-

MJ_CREATE : DesiredAccess:00100000 FileAttributes:00000000 SharedAccess:00000003 CreateDisposition:00000001 CreateOptions:00000021 File:/tmp
MJ_CREATE : DesiredAccess:00000080 FileAttributes:00000000 SharedAccess:00000007 CreateDisposition:00000001 CreateOptions:00200000 File:/tmp
MJ_CREATE : DesiredAccess:00000080 FileAttributes:00000000 SharedAccess:00000007 CreateDisposition:00000001 CreateOptions:00200000 File:/tmp
MJ_CREATE : DesiredAccess:00100000 FileAttributes:00000000 SharedAccess:00000003 CreateDisposition:00000001 CreateOptions:00000021 File:/tmp
MJ_CREATE : DesiredAccess:00100001 FileAttributes:00000000 SharedAccess:00000007 CreateDisposition:00000001 CreateOptions:00000021 File:/tmp
MJ_CREATE : DesiredAccess:00100000 FileAttributes:00000000 SharedAccess:00000000 CreateDisposition:00000001 CreateOptions:00800021 File:/tmp

I need to tie each of these lines up with the same functionality in xrdp and find out what the differences are.

[matt335672]

Not a great deal of success I'm afraid.

Below I've attached a patch from FreeRDP 3.7.0, and two log files from connecting to a Windows host and a Linux host.

freerdp-3.7.0.patch.txt windows.log linux.log

The bottom line is the Windows log is a lot more verbose, but the IRP_MJ_CREATE which is actually used for the directory listing is essentially using the same parameters as the Linux version.

I'd wondered if the filename could be the problem, but this isn't it; ls -la thinclients/D/jt does not work, but ls -lad thinclients/D/jt does.

I think I've reached the end of what is possible without looking at the other end as well. As far as I can tell we're completely compliant with the standard. I could be missing something of course, but if we are that suggests Dell are assuming some sort of RDP server behaviour which isn't actually documented.

@jt-fuw - some questions for you:- 1) You say you're running ThinOS 8.8, but I can't find any reference to that on the web. I take it you mean 8.6? 2) Have you tried xrdp with ThinOS 9.x? 3) Do you have any support contract with Dell on these boxes?

Thanks, and sorry to not have better news for you.

[matt335672]

I see I'm behind the times, and ThinOS 24xx is now available. Have you tried that release?

[jt-fuw]

You say you're running ThinOS 8.8, but I can't find any reference to that on the web. I take it you mean 8.6?

1. Sorry, my mistake: System Information - About tab says: Platform Name: 3020 Operating System: ThinOS Build Name: T10D_wnos Build Version: 8.5_024 BIOS Name: T10D_bios BIOS Version: 7.1_216 Citrix Receiver: 14.0.51952 Dell vWorkspace: 8.5 VMware Horizon: Microsoft RDP: 10.0 Imprivata: 5.5 Caradigm: 6.3 SECUREMATRIX: 4.1 HealthCast: 3.1

2. Currently I have 3 such a terminals, all having the same version. I didn't try installing a newer ThinOS.

3. No, they are second-hand devices.

[matt335672]

I don't know what else I can do at this point @jt-fuw. We've identified the failing packet exchange, and as far as I can tell, there's nothing wrong with what we're sending, although we're not as wordy as a Windows server. There appears to be no way of accessing the source code for the client end, and no possibility of support for it.

The only thing I can suggest is to try playing around with the values we're sending in the devredir_send_drive_create_request() call in devredir_get_dir_listing(). This is likely to be time-consuming with no guarantee of success.

[jt-fuw]

Hello. I wrote a modified patch for freerdp to print for debugging info from IRP's input/output streams, maybe it will show something that helps finding the bug.

Try it, or tell me how did you use the freerdp to make your tests.

I removed your debug printf-s (every line of them I preceded by "//D ") - if you assume some info from IRP or DRIVE_DEVICE structure can be useful, uncomment your lines.

I suppose adding timestamps to these printfs would be useful, it may help finding which packets are results of which commands.

jt.freerdp.patch.gz

[matt335672]

@jt-fuw - the problem is we can't get into the ThinOS software. There's no problem with the interaction between FreeRDP and xrdp, or even Windows and xrdp for that matter. We're sending a perfectly valid DR_CREATE_REQ to the ThinOS client, and it's responding with STATUS_INVALID_PARAMETER.

We're not using the exact same series of exchanges that Windows is using, but that shouldn't matter. As far as I can tell, we're compliant with the specification.

There only seem to be two ways to proceed from here:- 1) Get into the ThinOS software by reverse engineering it. I don't have a copy of the license agreement, but I'd be amazed indeed if that isn't prohibited. 2) Try varying the parameters in the initial DR_CREATE_REQ to see if we can find something that will work with version 8.5 of ThinOS.

Either of these is likely to be pretty time-consuming.

I can't see a way forward with FreeRDP. Am I missing something?

[jt-fuw]

Possibly some information is distorted or missed in some kind of packets.

It would be nice to see packets transferred in both directions. But this needs more deep diving into e.g. freerdp code. Till now, I don't know what is direction of these packet that are logged, nor what they contain.

Is there some good documentation of the protocol used? Possibly the source of the problem is a mismatch between the protocol interpretations.

[matt335672]

I've been through the packets pretty carefully and I didn't find anything. That's all in the attachments I've added above.

Protocol is documented in [MS-RDPEFS] with bits from other MS documents.