Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    metalefty
    @metalefty
    maybe LOG_DEVEL will suit
    to switch from LLOGLN
    matt335672
    @matt335672
    There's a PR pending neutrinolabs/xrdp#1767 to address the logging in XRDP. For now, LOG_DEVEL() is a good choice.
    aquesnel
    @aquesnel
    @metalefty thank you for taking the time to look at my pull requests.
    Nexarian
    @Nexarian

    @metalefty Here's what worked for me for now. Nexarian/xrdp@d06b37f

    Note this is a WIP branch so don't take too much stock in it.

    Do you know anything about the right want to invoke the send_server_monitor_resize function (that I just created) from the dynamic monitor response processor? There seems to be a lot of signaling mechanisms and it's hard to know which is which.

    ravi948
    @ravi948
    how to connect centos gnome existing session user with xrdp?
    Nexarian
    @Nexarian

    I figured out how to get xrdp_mm.c to communicate to xup.c! Now I can see resize messages being sent from the client all the way to the xorgxrdp backend. The key was the mod structures. Really xrdp_mod is the same as mod, but the idea is that they may have slightly different formats to allow for implementation details.

    Dynamic resizing is still not working however. I suspect I need to be cautious about the way the signaling mechanism works. Recently Jay had made some changes to the way xorgxrdp handles resize events, and it's possible those were oriented to resize-on-connection scenarios and aren't flexible enough to handle dynamic resizing of the xorgxrdp backend.

    Continuing to investigate. I'm really proud of the progress I've made on this thus far!

    Here is my latest change: Nexarian/xrdp@05a3a9a

    Nexarian
    @Nexarian

    It works now! To my knowledge, this is the first time dynamic monitor resizing has worked with XRDP!

    In the end, it was mostly a matter of taking the dynamic_monitor branch that Jay had already created, and then moving out the "on connect" screen resize functions such that they could be called from a network response function rather than only on session connect.

    Anyway, testing/comments appreciated. Build this custom branch and let me know: https://github.com/Nexarian/xrdp/tree/devel

    No changes to xorgxrdp are necessary.

    aquesnel
    @aquesnel
    @Nexarian congrats on getting resizing to work! I tried it out on my dev machine and my remote session resized with mstsc on win 10. I'm looking forward to seeing the pull request.
    matt335672
    @matt335672
    @ravi948 - can you address your question to the xrdp-questions room? This is a developer room. Thanks.

    @Nexarian - I haven't looked at your code so far, but I'm really pleased you're on board with looking at this!

    We got resize-on-reconnect working with the VNC backend working some time last year. I'll be happy to work with you on getting the dynamic resizing working with VNC when you get round to looking at it.

    metalefty
    @metalefty
    @Nexarian congrats!
    BTW, dynamic resizing has different meanings depending on the context. It is sometimes misleading. I think the word dynamic should be other words to be clear.
    metalefty
    @metalefty
    The one is resizing-on-reconnect as matt mentioned. Maybe on-the-fly-resizing (without reconnecting) will fit for the other one? There're two backends we can choose. So we have 2x2 matrix.
    Derek Schrock
    @derekschrock
    size-to-window?
    Nexarian
    @Nexarian
    FreeRDP uses "dynamic-resolution" for this feature... So it's pretty baked in unfortunately :)

    @aquesnel I wanted to talk to you more about issues I've seen in FreeRDP with this. I've noticed a lot of strangeness that I don't see on the Microsoft clients

    Also if you're using MSTSC you're missing out, use the App store version, it has the resize-on-the-fly feature!

    Nexarian
    @Nexarian
    And to be clear -- I'm talking about resize-on-the-fly working. XRDP has had resize-on-connect working for ages.
    aquesnel
    @aquesnel
    @Nexarian sure, just post your questions here or pm me
    Nexarian
    @Nexarian
    It seems like the problem is some protocol negotiation. The error looks like this:
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x1f size=49 channelId=1002)
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core] - transport_default_write:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_FINALIZATION - rdp_client_connect_demand_active() - -1
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core.rdp] - rdp_recv_tpkt_pdu: rdp_recv_deactivate_all() fail
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_FINALIZATION - rdp_recv_pdu() - -1
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core.rdp] - rdp_recv_tpkt_pdu: rdp_recv_deactivate_all() fail
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_FINALIZATION - rdp_recv_pdu() - -1
    [16:35:27:675] [15685:15686] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
    [16:35:27:675] [15685:15686] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
    [16:35:27:678] [15685:15686] [DEBUG][com.freerdp.core] - rdp_check_fds() - -1
    [16:35:27:678] [15685:15686] [INFO][com.freerdp.client.common] - Network disconnect!
    [16:35:27:682] [15685:15707] [DEBUG][com.freerdp.channels.drdynvc.client] - close_channel_iface: id=1
    It happens during capabilities negotiation, there's a bunch of back/forth about caps and a lot of PDUs are being exchanged, but at some point there is usually a failure in the protocol communication and the entire think winks out.
    Nexarian
    @Nexarian
    aquesnel
    @aquesnel
    I haven't seen this error before. Maybe with the extra trace logging and xrdp compiled with the debug flag that were added in commit 0ec471b, the logs will show what is in the synchronize message that is being sent and causing the error.
    aquesnel
    @aquesnel

    While working on #1802 I got build errors in the FreeBSD CI build: https://cirrus-ci.com/task/5691866718928896?command=configure#L8

    The error message is:

    ./bootstrap
    /usr/local/bin/autoconf
    /usr/local/bin/automake
    /usr/local/bin/libtool
    /usr/local/bin/pkg-config
    autoreconf-2.69: Entering directory `.'
    autoreconf-2.69: configure.ac: not using Gettext
    autoreconf-2.69: running: aclocal --force -I m4
    autom4te-2.69: need GNU m4 1.4 or later: /usr/local/bin/gm4
    aclocal: error: /usr/local/bin/autom4te-2.69 failed with exit status: 1
    autoreconf-2.69: aclocal failed with exit status: 1

    The diff from the last commit that successfully built on FreeBSD in that branch is https://github.com/neutrinolabs/xrdp/pull/1802/commits/b87c73eedd5def6980292eea141b07f7b4a6451a

    The previously successful build on FreeBSD can be found here: https://cirrus-ci.com/task/5676524592431104

    I have no idea why this is failing since both builds say that they are using the same FreeBSD-12-1 version. Does anyone have an idea of what's causing this failure or how to fix it?

    metalefty
    @metalefty
    i’ll have a look
    aquesnel
    @aquesnel
    thank you
    aquesnel
    @aquesnel
    for this FreeBSD build failure: I tried re-running a previously successful build and the re-run failed. So it's definitely not the xrdp code/config that is causing the failure.
    matt335672
    @matt335672

    @aquesnel @metalefty - I think I've found this. See neutrinolabs/xrdp#1804

    I'm nearly out of time today, but if the CI clears and I get time later I may merge this later today.

    metalefty
    @metalefty
    thank you! merged.
    matt335672
    @matt335672
    Quick question - does anyone know why we have a connection log for VNC and not for Xorg? It's a bit of an inconsistency, and I can't help feeling a connection log would help us sort out a few issues more quickly (although I haven't looked at it in a lot of detail yet). Thanks.
    metalefty
    @metalefty
    i think we should add such log if possible
    i’m not sure about the reason but maybe it is because nobody didn’t do that
    aquesnel
    @aquesnel
    The xup module logs connection requests to the xserver in the xrdp log file and back to the connecting user via the server_msg function
    https://github.com/neutrinolabs/xrdp/blob/8004a05a3233cacd1a7901ce05aabf909947b78e/xup/xup.c#L148
    matt335672
    @matt335672
    OK - thanks.
    The main reason I'm interested is we seem to have a lot of users that want to use the Xorg backend, but who don't get any information when the X server fails to start. Giving these users some more visual feedback may reduce some of the low-level issues that get reported in these instances.
    Nexarian
    @Nexarian

    @matt335672 My understanding is that the xorg backend was vastly superior to the VNC one in terms of capabilities and performance. Every time I try to use VNC it's unusably slow, not so with xorg.

    What is the advantage of the VNC backend relative to xorg?

    Also -- Any feedback as to why xorg isn't starting would be massively helpful. Normally it's black-screen-hell. I've seen everything from bad RSA keys to incorrect Nvidia drivers block it.

    Derek Schrock
    @derekschrock
    Using Xorg directly. I would expect this to be closer to a physical setup. Xorg is ran by the user vs Xorg being ran by gdm/root. Should be almost the same minus where it's logging.
    With Xorg you can also use RFX which is reduced bandwidth is most cases.
    I didn't test it with XVNC backend, xrandr functionally works with Xorg too. The remote Xorg knows of your physical monitor setup.
    @Nexarian Is your nivida config in a .d dir file?
    I've seen that happen with users before that have both a physical console setup but also want to use xrdp too.
    Derek Schrock
    @derekschrock
    I thought maybe had a solution to nvidia in .d dir conf. Maybe it was just moving to the xorg.conf that the phy. setup would have used.
    Nexarian
    @Nexarian
    I'm not having issues with XRDP now in terms of Nvidia... Although I wish the nvidia_hack branch would be spruced up and merged into master so that it's a standard feature now.
    I was only mentioning that in the past sometimes it's caused problems
    Nexarian
    @Nexarian
    And yes, nearly always I have a physical console setup.
    matt335672
    @matt335672

    @Nexarian - I agree that in theory Xorg should be able to replace Xvnc, but this isn't always the case.

    Xvnc has the advantages of being simple to understand. It won't set the world alight in terms of benchmarks, but it performs adequately over WAN links for many use-cases. I was using it for a few years in this way over a corporate WAN from home, although I wasn't doing anything graphically intensive. Some users have found it works better for them than Xorg - see for example this comment. It also supports login and connect to a VNC server which allows us to support things like MacOS, albeit in a limited fashion.

    Xorg can be much faster than Xvnc, but this speed increase comes at the expense of complexity and maintenance overhead. It requires more work to set up (see for example neutrinolabs/xrdp#1026 and also introduces a coupling on the X server internal interface version. The latter of these is important for longer-lived distros like Ubuntu LTS and CentOS. When the X server version changes, a new version of xorgxrdp is required and this isn't always apparent to the user - see for example all the confusion that the Ubuntu 18.04 HWE packages introduced. CentOS neatly avoids this by shipping Xvnc as the default config. There's also the breakage that can happen when the user is running NVidia drivers which you've already mentioned.

    For someone like you who has bought in to the whole xrdp architecture, there's little reason to consider Xvnc. For many first-time users in particular (many of whom raise issues which I end up addressing!) Xvnc is a simpler way to get started. Some of this can probably be addressed by better logging, but this needs changes to the architecture so that the user is informed when the X server fails to start in a more timely fashion.

    Happy to discuss this further. Come back at me if you disagree with any of the above.

    Nexarian
    @Nexarian

    VNC's main advantage has always been portability and simplicity, and what you've mentioned here aligns with that. I think it makes sense to have a "break glass/simple" configuration in case the fancier/super-car-style xorgxrdp isn't working. Very often in my job, I need some graphical remoting to do some things, like run an application that has graphical options that aren't available on the command line (yes, it's possible, even in Linux). And until xorgxrdp is better supported or more stable, I think it makes sense to have this as an "it just works" option that may have less feature-rich compatibility.

    I also think I agree that we need to invest heavily, and soon, into the reliability of the connection backend, be it VNC or Xorgxrdp. In my dynamic monitor testing, I can't get XRDP to connect properly the first time, I have to restart/re-sync often.

    Interestingly, in some of your investigations you've mentioned there were issues with the x-server and the ability to authenticate properly while maintaining different types of sessions. The maintainers of the ogon project have mentioned that one of the reasons their project has stalled out is they had fixes that need to be merged upstream into X before they feel the system will be ready for investment. I wonder if the issues both projects are facing are similar here.
    metalefty
    @metalefty
    I'm a little bit surprised that MS has suddenly archived linux-vm-tools: https://github.com/microsoft/linux-vm-tools