feat(acceptor): expose client multitransport flags on AcceptorResult#1453
Open
clintcan wants to merge 1 commit into
Open
feat(acceptor): expose client multitransport flags on AcceptorResult#1453clintcan wants to merge 1 commit into
clintcan wants to merge 1 commit into
Conversation
The acceptor already parses the client's GCC MultiTransportChannelData block (section 2.2.1.3.8) into ClientGccBlocks and then discards it, keeping only the early-capability flags, core desktop size, and keyboard layout. Surface the client's multitransport (MS-RDPEMT) capability flags on AcceptorResult so a server implementing UDP multitransport can decide whether to send a Server Initiate Multitransport Request. Purely additive, mirroring the existing keyboard_layout (Devolutions#1397) and desktop-size (Devolutions#1373) surfacing: a new AcceptorResult field, empty when the client sent no multitransport block, carried across a deactivation-reactivation. No behavior change.
clintcan
added a commit
to clintcan/macrdp
that referenced
this pull request
Jul 16, 2026
Log the read-side of vendored ironrdp-acceptor divergence (3) as upstreamed in Devolutions/IronRDP#1453 (opened 2026-07-17) — an additive twin of the merged #1397/#1373 GCC-surfacing. The M3c advertise/emit/offer half stays vendored (macrdp UDP-offer policy), so #1453 does not de-vendor the acceptor. TODO.md open-PR list + the vendored divergence (3) note updated to match.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The acceptor already parses the client's GCC
MultiTransportChannelDatablock (MS-RDPBCGR §2.2.1.3.8) intoClientGccBlocksduringBasicSettingsWaitInitialand then discards it, keeping only the early-capability flags, core desktop size, and keyboard layout. This surfaces the client's multitransport (MS-RDPEMT) capability flags onAcceptorResult.Why
A server implementing UDP multitransport needs to know whether the client advertised support (
SOFT_SYNC_TCP_TO_UDP,TRANSPORT_TYPE_UDP_FEC{R,L}) before deciding whether to send a Server Initiate Multitransport Request. Today that information is parsed and thrown away, so there's no way for a downstream server to see it.Shape
Purely additive, mirroring the existing
keyboard_layout(#1397) and desktop-size (#1373) surfacing of GCC client data the acceptor already parses:multitransport_flags: gcc::MultiTransportFlagsfield onAcceptor, captured fromgcc_blocks.multi_transport_channel;pub multitransport_flags: gcc::MultiTransportFlagsfield onAcceptorResult;No behavior change — the acceptor just stops discarding a block it already decodes.
cargo clippy -p ironrdp-acceptor --all-targetsandcargo fmt --checkare clean.