Public bug reported:
[Impact] Remmina's VNC plugin (and anything else using libvncclient1)
cannot connect to wayvnc (the Wayland VNC server used by Raspberry Pi
OS, Sway, Hyprland...). The TLS handshake and authentication succeed,
then the session is dropped a fraction of a second later. wayvnc/neatvnc
first announces a placeholder framebuffer (1280x720) and then sends an
ExtendedDesktopSize pseudo-rectangle resizing to the real output size
(e.g. 1920x1200). Its single screen has id 0. libvncclient 0.9.15's
HandleRFBServerMessage treats a screen with id 0 as invalid:
if (screen.id != 0 && screen.width && screen.height) { client->screen = screen;
}
else { invalidScreen = TRUE; }
if (!invalidScreen && ...) ResizeClientBuffer(...)
so the resize is silently skipped and the next full-frame update fails
the bounds check:
VNC returned: VNC authentication succeeded
VNC returned: Desktop name "WayVNC"
VNC returned: Connected to VNC server, using protocol version 3.8
VNC returned: Rect too large: 1920x1200 at (0, 0)
Remmina reports this to the user as "VNC connection timed out". A screen
id of 0 is valid in the RFB ExtendedDesktopSize extension; TigerVNC's
viewer handles the same server fine.
[Fix] Upstream merged the one-line fix on 2025-08-21:
https://github.com/LibVNC/libvncserver/pull/620 (commit
70cd7f43759dd50fd0a678b04a189d9cd735baae) "libvncclient: update screen
validation logic, because screen.id may equal 0" It drops the screen.id
!= 0 condition (one line in src/libvncclient/rfbclient.c;
libvncclient/rfbproto.c in 0.9.14). No upstream release contains it yet
(upstream issue #731 asks for a 0.9.16 for exactly this wayvnc
interoperability), so a cherry-pick is the only way Ubuntu users get it.
[Test Plan] Setup (server side — any Wayland desktop running wayvnc; the
reporter used Raspberry Pi OS Trixie on a Pi 5, wayvnc 0.9.1 / neatvnc 0.9.5
enabled via raspi-config → Interface Options → VNC, which configures PAM auth
and a self-signed TLS certificate):
note the display resolution (here 1920x1200); wayvnc initially announces a
1280x720 placeholder framebuffer and then resizes to the real size once capture
starts.
Steps to reproduce (client side, Ubuntu 26.04, libvncclient1
0.9.15+dfsg-3ubuntu0.2):
1.Start Remmina with debug output: G_MESSAGES_DEBUG=all remmina 2>&1 | tee
remmina.log2.
2.Create a VNC profile for the wayvnc host (any security type works — the
failure is after authentication; the reporter used VeNCrypt X509Plain with the
server's certificate as CA file; RSA-AES or a wayvnc password= config should
behave the same since the failure occurs after authentication — not separately
verified).
3.Connect and enter the credentials.
4.Observe the session close within ~1 s; Remmina shows "VNC connection timed
out".
Actual result — remmina.log ends with:
VNC returned: VNC authentication succeeded
VNC returned: Desktop name "WayVNC"
VNC returned: Connected to VNC server, using protocol version 3.8
VNC returned: Rect too large: 1920x1200 at (0, 0)
and wayvnc's log (wayvnc --log-level=debug) shows the corresponding
server side:
Info: User "USERNAME" authenticated
DEBUG: server.c: Client set encodings:
copyrect,hextile,raw,desktop-size,extended-desktop-size,...
DEBUG: server.c: Sending extended desktop resize rect: 1280x720
DEBUG: server.c: Sending extended desktop resize rect: 1920x1200
The client never logs "Updated desktop size: 1920x1200", i.e. the
ExtendedDesktopSize resize was discarded (screen id 0 → invalidScreen),
so the following 1920x1200 raw update exceeds the still-1280x720 client
framebuffer.
Expected result (with the patched libvncclient1): remmina.log contains
VNC returned: Updated desktop size: 1920x1200
and the remote desktop is displayed and keeps following server-side
resizes.
Regression test: with the patched package, connect to a libvncserver-
based server (e.g. x11vnc) — it must still connect, render and follow
resizes as before. Note that TigerVNC's Xvnc also sends screen id 0
(that is the case upstream PR #620 was written for), so a TigerVNC
server is a second positive test of the fix rather than a regression
control.
Affected releases: resolute (0.9.15) and noble (0.9.14+dfsg-1ubuntu0.2)
both carry the screen.id != 0 condition (verified in the packaged
sources); questing (0.9.15) as well.
[Where problems could occur] The change only relaxes validation of the
ExtendedDesktopSize screen list (a screen with id 0 but non-zero
width/height is now accepted). A server sending a zero-sized screen is
still rejected as before. Risk is limited to clients of libvncclient
handling a resize they previously ignored.
[Environment] Ubuntu 26.04.1 LTS, libvncclient1 0.9.15+dfsg-3ubuntu0.2,
remmina 1.4.43+dfsg-0ubuntu0.26.04.2, server: wayvnc 0.9.1 / neatvnc
0.9.5 (Raspberry Pi OS Trixie, arm64). Reproduced 2026-09-05.
** Affects: libvncserver (Ubuntu)
Importance: Undecided
Status: New
** Tags: noble resolute
** Patch added: "Upstream fix, libvncserver commit 70cd7f4 (PR #620)"
https://bugs.launchpad.net/bugs/2166587/+attachment/5997822/+files/libvncserver-upstream-pr620-screen-id-0.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166587
Title:
libvncclient rejects ExtendedDesktopSize resize when screen id is 0
(wayvnc/neatvnc) → "Rect too large", connection dropped — fixed
upstream in PR #620, please cherry-pick
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvncserver/+bug/2166587/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
