Display in connection string not honoured when trying to attach to a running session

[subjut]

I have a xpra (4.2.3) proxy server running on Ubuntu 20.04 as a system service configured to be connected to with ssl and the self signed default certificate. With the Windows client (x86_64_4.3-r29365), the display option in the connection string is not honored when attaching to a running session. Instead a new session is started with a different display, usually the first available.

This is the sequence of commands used:

xpra start ssl://test:password@[IP]:[PORT]/5 --start-child=xterm --ssl-server-verify-mode=none

This works fine and the xterm window is shown.

xpra list then shows

Found the following xpra sessions:
/run/user/1001/xpra:
     LIVE session at :5
/run/xpra:
     LIVE session at :20  [this is the proxy server]
/run/test/.xpra:
     LIVE session at :5

After disconnecting the windows client, not closing the xterm window, I run:

xpra attach ssl://test:password@[IP]:[PORT]/5 --ssl-server-verify-mode=none

xpra list:

Found the following xpra sessions:
/run/user/1001/xpra:
     LIVE session at :1
     LIVE session at :5
/run/xpra:
     LIVE session at :20  [this is the proxy server]
/run/test/.xpra:
     LIVE session at :1
     LIVE session at :5

I have also tested this from a remote Ubuntu vm running the latest xpra version from the repository (4.2.3-r12) with the same results.
This raises the problem, that there is no way to reconnect to the session at display :5 after disconnecting and leaving the xterm window open.

[totaam]

Works for me with master and 4.2.x on Fedora.
Worked with master on Ubuntu. Will try 4.2.x later.

[subjut]

If it helps, this is the proxy service config:

/usr/bin/xpra proxy :20 --daemon=no \
    --tcp-auth=${TCP_AUTH} \
    --ssl-cert=/etc/xpra/ssl-cert.pem --ssl=on --ssl-auth=sys \
    --bind-ssl=0.0.0.0:[PORT] --auth=${AUTH} --socket-dirs=/run/xpra --socket-permissions=666 \
    --log-dir=/var/log --pidfile=/run/xpra/proxy.pid --debug=${DEBUG}

[totaam]

Also works for me on Ubuntu 20.04 with a default config, fresh install:

• 4.2.3-r28496 (build from current 4.2.x branch)
• 4.3-r30283 from beta repo

The bug only occurs with 4.2.3-r12-2 from the stable repo

This is the same bug discussed in #3276 - already fixed.