https://bugs.kde.org/show_bug.cgi?id=524610
Bug ID: 524610
Summary: KRFB 26.08.0 does not start VNC listener - downgrading
to 26.04.3 restores it
Classification: Applications
Product: krfb
Version First 26.08.0
Reported In:
Platform: Other
OS: Other
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
KRFB 26.08.0 starts and remains running, but does not create a VNC/RFB
listening socket. VNC clients receive "connection refused".
Downgrading only the "krfb" package from 26.08.0 to 26.04.3, without changing
the configuration or other KDE/Qt packages, restores the VNC listener and
remote connections.
STEPS TO REPRODUCE
1. Run Plasma X11 with KRFB configured for desktop sharing and unattended
access.
2. Start KRFB 26.08.0.
3. Verify that the process is running:
pgrep -a krfb
4. Check for the VNC listener:
ss -ltnp | grep -E 'krfb|:590[0-9]\b'
5. Attempt to connect with a VNC client.
OBSERVED RESULT
With KRFB 26.08.0:
* /usr/bin/krfb remains running.
* No TCP socket is opened on port 5900 or any other 590x port.
* A VNC client receives "connection refused".
* There is no firewall blocking the port.
Example:
$ pacman -Q krfb
krfb 26.08.0-1
$ pgrep -a krfb
10255 /usr/bin/krfb
$ ss -ltnp | grep -E 'krfb|:590[0-9]\b'
no output
I also tested changing the framebuffer backend from PipeWire (pw) to the X11
xcb backend. KRFB still did not create a VNC listener, so the problem does not
appear to depend on the selected framebuffer backend.
EXPECTED RESULT
KRFB should start an RFB/VNC listener as it did with 26.04.3, allowing VNC
clients to connect.
REGRESSION TEST
On the same running system, with the same KRFB configuration and without
downgrading Plasma, Qt, PipeWire, KPipeWire, or any other package, I downgraded
only KRFB:
krfb 26.08.0-1 -> 26.04.3-1
Immediately after starting KRFB 26.04.3:
$ pacman -Q krfb
krfb 26.04.3-1
$ pgrep -a krfb
14495 /usr/bin/krfb
$ ss -ltnp | grep -E 'krfb|:590[0-9]\b'
LISTEN 0 32 0.0.0.0:5900 0.0.0.0:* users:(("krfb",pid=14495,fd=16))
LISTEN 0 32 [::]:5900 [::]:* users:(("krfb",pid=14495,fd=17))
$ nc -vz 127.0.0.1 5900
Connection to 127.0.0.1 5900 port [tcp/rfb] succeeded!
Remote VNC access also works again with 26.04.3.
The Arch Linux package history shows that KRFB was upgraded from 26.04.3-1 to
26.08.0-1 immediately before the problem appeared.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
Graphics Platform: X11
Desktop: KDE Plasma
KRFB affected version: 26.08.0
KRFB working version: 26.04.3
Relevant installed versions while reproducing the issue:
krfb 26.08.0-1
kpipewire 6.7.4-5
kwin 6.7.4-7
pipewire 1:1.6.8-1
libpipewire 1:1.6.8-1
libvncserver 0.9.15-1
xdg-desktop-portal 1.22.1-2
xdg-desktop-portal-kde 6.7.4-2
Session environment:
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=KDE
DESKTOP_SESSION=plasmax11
ADDITIONAL INFORMATION / POSSIBLE REGRESSION SOURCE
Note: this is just speculation:
The regression may be related to commit
842c91e45dcc65a6b4a29e05b49cee7cd4acf2af, associated with bug 497071 and
intended to allow krfb-virtualmonitor to work without starting a VNC server
when no password is supplied.
That commit added a passwordSet property to the generic RfbServer. It defaults
to false, and RfbServer::start() now initializes the RFB server only when
passwordSet() is true.
krfb-virtualmonitor calls setPasswordSet(...), but I could not find an
equivalent initialization in the normal InvitationsRfbServer path.
Looks like normal KRFB inherits passwordSet == false and skips rfbInitServer(),
leaving the KRFB process running without a listening socket.
This is only a suspected cause, the reproducible regression is that KRFB
26.08.0 does not create a VNC listener while 26.04.3 does under identical
conditions.
--
You are receiving this mail because:
You are watching all bug changes.
