I dug into the FreeRDP sources and believe I found the root cause.
The regression comes from the new ChannelPduTracker introduced between 3.24.2
and 3.30.0 (libfreerdp/utils/channel_pdu_tracker.c, not present in 3.24.2).
It validates every incoming static virtual channel chunk against the
hard-coded minimum chunk size and buffers it in a fixed-size buffer:
libfreerdp/utils/channel_pdu_tracker.c (tag 3.30.0):
31: char buffer[CHANNEL_PDU_LENGTH]; /* 1600 + 8 bytes */
61: if (header->length > CHANNEL_CHUNK_LENGTH) /* 1600 */
63: WLog_Print(..., "chunk size %u is too big", header->length);
However, the FreeRDP server itself advertises a much larger chunk size to the
client in the Virtual Channel Capability Set:
libfreerdp/core/settings.c:1201 (tag 3.30.0):
freerdp_settings_set_uint32(settings, FreeRDP_VCChunkSize,
(server && !remote) ? CHANNEL_CHUNK_MAX_LENGTH /* 16256 */
: CHANNEL_CHUNK_LENGTH)
so VCChunkSize = 16256 is written into the server's capability set
(libfreerdp/core/capabilities.c, rdp_write_virtual_channel_capability_set).
Per MS-RDPBCGR 2.2.7.1.10, a client receiving this may send chunks up to the
advertised size, and Windows mstsc does exactly that: the chunk sizes from my
log (14382, 2220) are legal chunks below 16256 but above the tracker's
hard-coded 1600 limit. ChannelPduTracker_poll() then fails, and the cliprdr
server thread exits with error 13 (ERROR_INVALID_DATA) — after that every
clipboard operation in the session times out. Any clipboard payload larger
than ~1600 bytes kills the channel, which is why the clipboard appears
completely broken in practice.
In other words: the server advertises "chunks up to 16256 are fine" but its
own receive path rejects anything above 1600. The 3.24.2 code path (before
ChannelPduTracker existed) reassembled chunks without this check, which is
why downgrading fixes it.
I checked upstream master (FreeRDP/FreeRDP) today and the same hard-coded
check is still present there, so this needs an upstream fix as well. The fix
would be to validate against the negotiated VCChunkSize instead of
CHANNEL_CHUNK_LENGTH and size the reassembly buffer for
CHANNEL_CHUNK_MAX_LENGTH + sizeof(CHANNEL_PDU_HEADER).
Happy to file the upstream issue if that helps.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161573
Title:
Clipboard broken in gnome-remote-desktop after freerdp3 update to
3.30.0: cliprdr channel thread dies with "ChannelPduTracker_poll:
chunk size is too big"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp3/+bug/2161573/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
