Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    aquesnel
    @aquesnel
    @metalefty when you become available again can you please take a look at merging #1767 and #1742
    aquesnel
    @aquesnel
    @matt335672 your SCP wiki page makes sense to me. Good detective work figuring out the SCP history.
    AlbertPallardo
    @AlbertPallardo
    How can I change xrdp password?
    Derek Schrock
    @derekschrock
    AlbertPallardo: In most cases it's just he user's password.
    Otherwise it's the backing server if you're connecting to VNC server.
    Nexarian
    @Nexarian
    Hey all -- I've been a long time fan of XRDP, and now I've decided it's time to apply my development skills to try to help solve an issue. My background is mainly in cloud programming (Java/Python/Perl), but once upon a time I did teach myself C. Anyway, I'm passionate about this one: neutrinolabs/xrdp#448, and I think it's accessible enough for someone who has little XRDP experience to tackle. I've started putting my notes in the issue, and any thoughts/advice are appreciated!
    metalefty
    @metalefty
    @aquesnel Hi, I still have been busy with my main job. Regarding #1742, LGTM.
    metalefty
    @metalefty
    @Nexarian welcome!
    Nexarian
    @Nexarian
    @metalefty Thanks! Right now I'm trying to figure out the best way to configure logging. The code for dynamic monitor is in the xrdp_mm.c file, and the LLOGN functions seem a bit strange, what is the right way to use them?
    metalefty
    @metalefty
    @Nexarian we're now switching LLOGLN to new log macros.
    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.