Support for the RDP Multitransport Layer

[CBenoit]

TODO comment in code.

clientMultitransportChannelData (8 bytes): Optional Client Multitransport Channel Data structure (section 2.2.1.3.8). This field MUST NOT be included if the server did not advertise support for Extended Client Data Blocks by using the EXTENDED_CLIENT_DATA_SUPPORTED flag (0x00000001) as described in section 2.2.1.2.1.

Source

[glamberson]

Hey,

I have a working RDPEUDP2 + RDPEMT implementation that I want to wire up to IronRDP for testing. It needs a few small upstream changes that I've split into separate PRs.

PRs 1, 2, and 4 are purely additive and shouldn't affect existing behavior:

• PR 1 adds MultitransportRequestPdu and MultitransportResponsePdu types to ironrdp-pdu ([MS-RDPBCGR] 2.2.15.1, 2.2.15.2)
• PR 2 lets the connector advertise multitransport support in the GCC blocks, resolving the TODO at connection.rs line 728 ([MS-RDPBCGR] 2.2.1.3.7)
• PR 4 adds SvcMessage::encode_raw() to ironrdp-svc so DVC messages can be encoded without SVC channel headers (needed for UDP where DVC data bypasses the chunking layer)

PR 3 depends on PR 1 and adds a peek-based dispatch in decode_io_channel() to handle multitransport PDUs on the IO channel. These use BasicSecurityHeader instead of ShareControlHeader, so the existing decode path needs a two-byte check before falling through to decode_share_control().

For the connector state machine itself, my thinking is that MultitransportBootstrapping should surface the server's request as output and let the application handle the UDP side externally — RDPEUDP2 handshake, RDPEMT tunnel setup — then feed back success or failure. The connector would then encode and send the MultitransportResponsePdu on the IO channel. This keeps the connector sans-I/O and transport-agnostic, which seems consistent with how it handles everything else. But this touches core connector architecture so I'm open to a different approach if you have something else in mind.

Greg Lamberson
Lamco Development
greg@lamco.io