No RDP on ChromeOS

[noseshimself]

Describe the bug
As soon as an RDP connection is started asbru-cm is dumping a core.

To Reproduce
Steps to reproduce the behavior:

1. Create an RDP connection using rdesktop or freerdp-x11 as methof
2. try using it
3. See error

Expected behavior
A connection being started

Environment (please complete the following information):

• OS: Linux container within ChromeOS 106 identifying as "Linux penguin 5.10.136-19393-g8d1faf8b57d7 Add screenshots #1 SMP PREEMPT Wed Oct 5 03:05:49 PDT 2022 x86_64 GNU/Linux" which is more or less a Debian 11
• Ásbrú Version [e.g. 6.1.1 or 6.2.0 or loki] Ásbrú Connection Manager 6.3.3 (asbru-cm)

Additional context
Terminal output:
(asbru-cm:6896): Gdk-WARNING **: 02:02:59.658: ../../../../../gdk/x11/gdkwindow-x11.c:5653 drawable is not a native X11 window
[xcb] Unknown sequence number while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
perl: ../../src/xcb_io.c:153: append_pending_request: Assertion `!xcb_xlib_unknown_seq_number' failed.

The x11 inside the Linux VM is based on wayland inside wayland. It might be better to use freerdp2-wayland instead.

[gfrenoy]

Don't have a ChromeOS to test this, sorry.

Did you try to run the command line generated by Ásbrú outside Ásbrú ? I mean, Ásbrú cannot do better than freerdp so please first double check it works outside Ásbrú.

[noseshimself]

Did you try to run the command line generated by Ásbrú outside Ásbrú

No. I didn't even see it; what should I look at?

Besides that "imagine a minimal Debian system without any GUI stuff installed that magically has a few strange environt variables like

GTK_IM_MODULE=cros
XDG_CONFIG_HOME=/home/user/.config
XCURSOR_SIZE=24
DISPLAY_LOW_DENSITY=:1
WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
XDG_CURRENT_DESKTOP=X-Generic
WAYLAND_DISPLAY=wayland-0
SOMMELIER_DRM_DEVICE=/dev/dri/renderD128
TERM=xterm-256color
DISPLAY=:0
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/home/user/.local/share:/home/ap/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
BROWSER=/usr/bin/garcon-url-handler "

[gfrenoy]

In the connection settings, go to Connection > Advanced Parameters and click the `Get Command line" button.

You should run that same command in a shell outside Ásbrú and see if this works differently.

If it does not work using the same command line, I do fear we cannot do much and you should get some help from the ChromeOS team.

[noseshimself]

Command Line:
xfreerdp  /bpp:24  -5 -a 24 -r sound:off -r clipboard:PRIMARYCLIPBOARD /t:"hyper-v" /v:192.168.192.93:3389

Proxy setup:
ssh -F "/home/ap/.config/asbru/tmp/a5c72d20-1c39-48b4-80a4-c037db5084cd.conf" -S "/home/ap/.config/asbru/tmp/a5c72d20-1c39-48b4-80a4-c037db5084cd.ctl" -f -N -T -M -L :192.168.192.93:3389 jumpserver

-L :192.168.192.93:3389 jumpserver is looking a bit fishy -- there should be a local port in that definition and jumpserver would have to be replaced by the actual host name and port number.

The command line is actually trying to connect

If I use the command line

xfreerdp /bpp:24 -5 -a 24 -r sound:off -r clipboard:PRIMARYCLIPBOARD /t:"hyper-v" /v:192.168.200.163:3389
to connect to a local Windows machine

[14:42:09:538] [1227:1227] [ERROR][com.winpr.commandline] - Failed at index 1 [/bpp:24]: Invalid sigil

and -5 -a 24 -r sound:off -r clipboard:PRIMARYCLIPBOARD is making xfreerdp unhappy, too.

xfreerdp /v:192.168.200.163 (the local test host) is working fine, it's just looking like 1999; using wlfeerdp is looking a lot better.

rdesktop -5 -a 24 -r sound:off -r clipboard:PRIMARYCLIPBOARD -T "hyper-v" local-target:3389 is working flawlessly.

If I'm running a correct ssh invocation (-L port:target:port) it is working across the ssh tunnel, too, so I have to assume that it is the surrounding asbru infrastructure that is hitting a wall.

I still believe that there is an assumption of a full GTK installation available which is not fitting the minimalist Debian environment.

[gfrenoy]

Thanks for the additional information, so it looks like there is a mix between options for xfreerdp and rdesktop ?!

So not sure this is related to ChromeOS, there must be something else. The missing local port is also something to investigate.

Do you have both installed ?
Does it also mix the parameters if you don't use a jump server ?

[noseshimself]

I currently hav xfreerdp, wlfreerdp and rdesktop installed.

I just added remmina and now I guess I got something really useful but did n ot have time to look into your source code: remmina isn't working either, it's just not crashing doing so. Instead I'm getting an error that it can't connect to 127.0.0.1:3389.

To me it is looking like there is a problem with the ssh tunnel, not the RDP connection. While tcpdump is showing packets being exchanged between jump host and client even at log level debug2 absolutely nothing is getting into the sshd log file on the jump host.

Executing a correct ssh command and using its local port for the RDP session out of asbru is working too.

Is there a way to trace what's happening when setting up the ssh tunnel and for you to gracefully handle unexpected errors?

[gfrenoy]

-L :192.168.192.93:3389 jumpserver is looking a bit fishy

Ok I found that one. When displaying the command, the local port was not shown correctly but when Ásbrú is actually launching it, it will be defined correctly. I'll fix this for the next version.

I setup a small lab here and tried to reproduce the case : both xfreerdp and rdesktop installed, connection through a jump server.

And, ... all is working as expected.

I don't see the "mix" of options you are seeing in the command line, that likely the root issue to find out.

Maybe one idea: did you switch the connection type from "rdesktop" to "freerdp" (or vice versa) ? Did you try to recreated the "freerdp" connection from scratch ?

Is there a way to trace what's happening when setting up the ssh tunnel

Not much traces available in that part of the code today.

What I would suggest is to use ps aux (or anything similar) and look at the commands that are supposed to be running (the same command lines as shown in the "advanced options". If they are not running, they died for some reason.

You should also see the traces of freerdp in the terminal window. Don't you see anything useful there.

gracefully handle unexpected errors

Not much either but any error message shall be see in the RDP terminal window.

[noseshimself]

Maybe one idea: did you switch the connection type from "rdesktop" to "freerdp" (or vice versa) ? Did you try to recreate the "freerdp" connection from scratch ?

Whenever you create a new session it starts out as "ssh" anyway; you have to edit it in any case. I tried but it did not change anything.

What I would suggest is to use ps aux (or anything similar) and look at the commands that are supposed to be running (the same command lines as shown in the "advanced options". If they are not running, they died for some reason.

There is no opportunity to get that done; the root is gone by the time I could even consider to start typing.

My best guess is that the ssh tunnel setup is failing, whatever tries using the tunnel doesn't check for its presence at all, fails to connect in a spectacular way and entire asbru-cm dies.

But my guess might actually be wrong. I tried strace on asbru-cm and the process that is crashing is the initial asbru-cm itself, immediately after the message Gdk-WARNING **: 23:19:59.283: ../../../../../gdk/x11/gdkwindow-x11.c:5653 drawable is not a native X11 window:

recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\26\0\0\0\0\0\10\0", iov_len=1516}, {iov_base="", iov_len=2580}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 8
poll([{fd=6, events=POLLIN}], 1, -1)    = 1 ([{fd=6, revents=POLLIN}])
recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\30\0\0\0\0\0\f\0003`\0\0\1\0\0\0\1\0\f\0\30\0\0\0", iov_len=1508}, {iov_base="", iov_len=2588}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
futex(0x7a338d6f2f38, FUTEX_WAKE_PRIVATE, 2147483647) = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
getpid()                                = 23666
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
write(2, "\n(asbru-cm:23666): Gdk-\33[1;33mWA"..., 149) = 149
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x90} ---
+++ killed by SIGSEGV (core dumped) +++

and whatever is happening it's triggered by sending and receiving data on file descriptor 6 which is (asbru.trace.23666:connect(6, {sa_family=AF_UNIX, sun_path="/run/user/1000/wayland-0"}, 27) = 0) the connection to the Wayland server.

I guess you will need a Wayland-infested system for debugging this.

[gfrenoy]

I guess you will need a Wayland-infested system for debugging this.

Yes. I tried on Fedora 37 and got this:

(asbru-cm:4029): Gtk-WARNING **: 07:58:41.496: GtkSocket: only works under X11

(asbru-cm:4029): Gdk-WARNING **: 07:58:41.496: ../gdk/x11/gdkwindow-x11.c:5653 drawable is not a native X11 window
GLib-GObject-WARNING **: invalid cast from 'GdkWaylandDisplay' to 'GdkX11Display' at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67.
Segmentation fault (core dumped)

This cannot be obvious enough, it does not work with Wayland :-/

So at the end of the day, this is actually a duplicate of #974, isn't it ?

[noseshimself]

No, not at all.

ChromeOS is providing a tool (named sommelier) to forward connections from the Linux container inside a Linux VM to the "real" Wayland server running on the host. I'm ending up with this

DISPLAY_LOW_DENSITY=:1
WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
WAYLAND_DISPLAY=wayland-0
DISPLAY=:0

in my environment and a "real" X application should never know that there is a Wayland server it could even talk to (this is coming at a cost like X applications getting appropriate scaling to make 96dpi the expected 96dpi no matter what the real dot pitch is and becoming a bit blurry). Even ancient pure X applications like xeyes are (nearly) working as expected (due to layering they can't track the mouse outside their window and look like having a stroke). So unless some part of your application or library tree is explicitly looking for WAYLAND_DISPLAY and trying to connect to the Wayland proxy the application should have been completely unaware of it -- sommelier is more or less an X11 server with Wayland as back end.

All X11 and Qt (and Gnome) libraris on the system are standard Debian packages; there are no special considerations for this environment.

asbru is actually the only application who ever showed this kind of behavior and it does not matter whether I'm using the appimage, a packaged version or compiling it myself against my local libraries...