Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    matt335672
    @matt335672

    @Nexarian - I've not seen ogon before. Thanks for the heads up. It wouldn't surprise me if the same issues are being faced by both projects.

    Can you be a bit more specific about the connection issues you're having? Is it the xrdp connection to sesman, or something else? I've not had any significant issues here.

    10 replies
    matt335672
    @matt335672
    @metalefty - yes, that's a bit unusual. I'm aware that a few users have raised issues with the Hyper-V Quick Create, but I've not had a suitable system available to reproduce them. I suspect there's not a lot we can do about them anyway, except raise issues against Ubuntu on Launchpad.
    1 reply
    metalefty
    @metalefty
    vsock support was added by MS guys for Hyper-V quick create. If they abandon vsock, we may be remove it in future.
    in short term, i don’t have any plan to remove vsock but if it become unmaintainable it might be removed.
    Nexarian
    @Nexarian
    I wish the XRDP community had a contact/mole/resource within Microsoft. Coldly reimplementing the spec is annoying.
    arops2020
    @ar2020-devops
    Hello Team
    Need some help on some information

    I am Looking for setting up a message in Banner for Linux server while loggin usinf xrdp. I tried to add my banner msg in this file /etc/xrdp/xrdp.ini :

    ; Login Screen Window Title
    ls_title=

    But its no success. I have restarted the xrdp service as well. Any help/Suggestion. Thanks and Advance.

    jsomiak1
    @jsomiak1
    hi, i need lil information, i need to know its anyway for see my incoming connections to my rdp, where the connection from?
    Nexarian
    @Nexarian
    Made more progress on dynamic monitor last night. I suspect the crashes I'm seeing are because xrdp and xorgxrdp gets out of sync
    So I need to either re-use an existing way to keep them in sync, or add one.
    Nexarian
    @Nexarian
    I think this is what I need to use: neutrinolabs/xrdp@21f90e3
    Nexarian
    @Nexarian

    Ugh, trying it does indeed seem to help, but it breaks the Microsoft Remote Desktop client, so must keep digging.

    Does anyone have tips on debugging why something might work with FreeRDP but not with the Microsoft versions?

    matt335672
    @matt335672
    No particular tips on debugging that I'm afraid.
    A lot of your crashes seem to be related to the timer callback (IIRC). Is it possible that some of those callbacks are working with stale info, and that's causing your crashes? I'm away from a development environment at the moment I'm afraid, so working from memory.
    Nexarian
    @Nexarian

    I'm trying to think how I might force the callbacks to work with up-to-date memory. Essentially this is a pretty fundamental shift for the driver in this regard. The size of video memory could shift at any time, whereas before a baked-in assumption was that it would only change during connection time.

    So -- How to fix that? A couple ideas off the top of my head:

    1. Protect the relevant memory with a mutex and an interrupt signal. Fire the interrupt on any changes which will prompt the capture callback to release the mutex, and no other callbacks will be allowed to access the memory due to the resizing algorithm consuming the mutex.
    2. Add checks within the capture callback to make sure that it's always using up-to-date memory.
    3. My attempt at using suppress sorta kinda helped in some circumstances, but because this is a timer callback it's operating on a different thread, which means I can't force the data to always be consistent.
    4. Protect every interaction with the memory buffer with a size check instead of a mutex -- This seems more extreme and probably would impact performance.
    Nexarian
    @Nexarian

    Then again, the entire reason the suppress output was created was to prevent the driver from writing to memory when the window was minimized -- Because that narrow use-case is in effect a resolution change, but under a very specific circumstance.

    Fun fact: In Windows 95, it never actually minimized the windows. Instead, it just moved them off to (MAX_INT, MAX_INT) in virtual video memory. If you ever had a display that could show that much resolution, you would never see anything minimize, so there were some people who came up with hacks, like scaling the desktop in the extreme, to be able to see it :)