RDP: follow GNOME Remote Desktop server-redirection PDU (EGFX negotiates; GRD black-screens on redirect)

[GlassOnTin]

Context

GNOME Remote Desktop's RDP backend (gnome-remote-desktop-daemon, FreeRDP-server-side) requires the client to advertise EGFX (MS-RDPEGFX, the Graphics Pipeline Extension) in its confirmActive capabilities. Reported on #109 by @agevlakh — server-side journalctl shows:

[RDP] Client did not advertise support for the Graphics Pipeline, closing connection
[ERROR] freerdp_peer::Capabilities() callback failed
[ERROR] [rdp_peer_handle_state_demand_active]: 
  [CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE] failed

Without EGFX, GRD bails during caps validation, before sending ServerDemandActive. Haven sees the channel close as "unexpected Share Control PDU" because the expected PDU never arrives.

xrdp and Microsoft Windows hosts still ship bitmap updates via the legacy path even when the client lacks EGFX. GRD is the strict outlier here, and increasingly the default RDP server on modern Linux desktops (Fedora 41+, Ubuntu 24.04 GNOME, etc.).

Scope

IronRDP has the building blocks but not the integration:

• ✅ ironrdp-pdu defines dvc::gfx::ServerPdu / ClientPdu and the EGFX message types
• ✅ ironrdp-dvc implements DRDYNVC (Dynamic Virtual Channel) framing
• ✅ ironrdp-graphics exists with codec primitives
• ✅ ironrdp-replay-client example consumes EGFX from a recorded stream
• ❌ ironrdp-session does not currently negotiate EGFX as a client in-session
• ❌ No glue connecting decoded EGFX surfaces to Haven's RdpScreen display path

Work breakdown

1. Negotiation: advertise EGFX in confirmActive capabilities; open the Microsoft::Windows::RDS::Graphics dynamic VC over DRDYNVC after capability exchange.
2. Protocol handling: handle RDPGFX_CAPS_ADVERTISE_PDU / RDPGFX_CAPS_CONFIRM_PDU, frame ACKs, surface create/delete, surface-to-output, cache import/export.
3. Decoders: at minimum RemoteFX (RFX) and NSCodec for Linux servers; AVC420/AVC444 (H.264) for Windows hosts already on EGFX. May be possible to advertise only what we can decode and let the server pick.
4. Display integration: route decoded surface tiles into the existing RdpScreen Bitmap + Compose canvas path that legacy bitmap updates already use.
5. Frame-ack timing: GRD requires timely frame ACKs or it stops sending updates.

Affected users

Anyone using:

• Fedora 41+ default GNOME (RDP enabled in Sharing panel)
• Ubuntu 24.04+ GNOME with RDP sharing
• Any system that picked up GRD's RDP backend (which Wayland-first distros increasingly default to)

Currently shows as "unexpected Share Control PDU" with NLA on, or "HYBRID_REQUIRED_BY_SERVER" with NLA off (since GRD doesn't fall back to TLS-only).

References

• RDP error #109 — original report (agevlakh, GRD on Fedora)
• IronRDP#1232 — asked Devolutions to surface PDU type in the error string
• IronRDP roadmap discussion would be the right place to flag this externally — they're likely to take an EGFX implementation upstream

Workaround until implemented

For users on GRD: switch to xrdp on the same host. apt install xrdp / dnf install xrdp then systemctl enable --now xrdp and disable RDP in GNOME Settings → Sharing. Less polished but works with bitmap updates.

[GlassOnTin]

Update: implementation landed in v5.24.69 — needs testing against GRD

The EGFX client work shipped in v5.24.69 (commits 3eaecf87..486764d4). Status against the work breakdown above:

Item	Status
1. Negotiation — SUPPORT_DYN_VC_GFX_PROTOCOL early-cap bit + DRDYNVC + open the Microsoft::Windows::RDS::Graphics channel	✅ shipped
2. Protocol — RDPGFX_CAPS_ADVERTISE_PDU / CAPS_CONFIRM_PDU, surface create/delete/map/copy/solid-fill, 64-slot tile cache	✅ shipped
3. Decoders — ClearCodec + RemoteFxProgressive (RLGR1, lShift, extrapolate-mode IDWT, YCbCr→RGBA)	✅ partial — covers ~93% of typical Windows tiles in our trace; AVC420/AVC444 (H.264) not implemented; UPGRADE refinement-pass logged + skipped
4. Display — surface→host-framebuffer projection on EndFrame, coalesced bounding-box repaint	✅ shipped
5. Frame ACK timing — FrameAcknowledge after every EndFrame	✅ shipped

Verified end-to-end against Windows Server 2025 NLA (the v5.24.69 changelog has the trace summary). xrdp keeps working through the slow-path fallback (no regression).

Not yet verified: gnome-remote-desktop. The capabilities are now on the wire and the channel opens, so GRD shouldn't hit Client did not advertise support for the Graphics Pipeline any more. But what GRD actually sends across that channel — its codec mix (RFX? NSCodec? AVC?) and frame-ack pacing — hasn't been observed in our test traffic. There's a real chance v5.24.69+ now connects to GRD and renders, and an equally real chance GRD picks a codec we don't decode yet (AVC444 in particular would still surface as blank/black tiles).

@agevlakh — when you have a moment, would you mind retesting your Fedora GRD setup against v5.24.76 (current, includes a Gboard-typing fix that's irrelevant here but no point testing on stale code)? With NLA on, both the original Client did not advertise... log line and any subsequent rendering should tell us where we are. A logcat of the Haven side and a journalctl -u gnome-remote-desktop excerpt covering one connection attempt would be ideal.

If GRD picks AVC, that's the next blocker and a separate piece of work — IronRDP has the AVC primitives in ironrdp-graphics but the in-session decoder integration is what's missing.

Workaround in the issue body (xrdp instead of GRD) still applies if v5.24.76 doesn't render.

[agevlakh]

when you have a moment, would you mind retesting your Fedora GRD setup against v5.24.76
@GlassOnTin ok, no problem. I will test it with feedback 👍

[agevlakh]

@GlassOnTin 5.24.81 rdp connected , but black screen, use ip, user and password on connection setup. NLA on
Logs on fedora:

anton@cerebro:~$ journalctl -f -u gnome-remote-desktop   
мая 02 16:40:39 cerebro gnome-remote-desktop-daemon[976]: Client does not support autodetecting network characteristics (RTT detection, Bandwidth measurement). High latency connections will suffer!                               
мая 02 16:40:40 cerebro gnome-remote-desktop-daemon[976]: [RDP] Sending server redirection                        
мая 02 16:40:40 cerebro gnome-remote-desktop-daemon[976]: [16:40:40:624] [976:00000b5f] [ERROR][com.freerdp.core.transport] - [transport_read_layer]: BIO_read retries exceeded                                                     
мая 02 16:40:40 cerebro gnome-remote-desktop-daemon[976]: [16:40:40:624] [976:00000b5f] [ERROR][com.freerdp.core.peer] - [transport_read_layer]: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]                                   
мая 02 16:40:40 cerebro gnome-remote-desktop-daemon[976]: [RDP] Network or intentional disconnect, stopping session                                                        

[GlassOnTin]

@agevlakh — really useful logs, thank you. They show the EGFX negotiation succeeded (no more "Client did not advertise support for the Graphics Pipeline") — that's the v5.24.69+ work paying off. The new failure is different: GRD is sending an RDP server-redirection PDU (MS-RDPBCGR § 2.2.13.1) and Haven/IronRDP doesn't follow it.

[RDP] Sending server redirection
[transport_read_layer]: BIO_read retries exceeded
[ERRCONNECT_CONNECT_TRANSPORT_FAILED]

Server redirection is GRD's way of saying "disconnect and reconnect to this other endpoint" (originally a Terminal Services load-balancing feature; GRD reuses it for some session-handover logic). Haven sees the redirect PDU, ignores it, the original transport eventually times out, you see a black screen and a disconnect.

So the GRD blocker chain is now:

1. EGFX negotiation — fixed in v5.24.69
2. SUPPORT_DYN_VC_GFX_PROTOCOL early cap — fixed in v5.24.69
3. Server redirection support — current blocker, captured as a separate piece of work
4. Codec coverage (AVC420/AVC444 if GRD eventually sends those) — still unverified, can't see what's on the wire until Adding new connection then rotate or touch outside #3 is past

Server redirection is meaningful Rust work in rdp-kotlin/IronRDP — parse the PDU, disconnect cleanly, reconnect to the redirect target while preserving NLA + cookies. It's not landing in this week's v5.24.82 (that's unrelated rclone-OAuth UX cleanup) but it's now the highest-priority RDP item.

The xrdp workaround in the issue body still applies if you need the host reachable in the meantime: dnf install xrdp && systemctl enable --now xrdp then disable RDP in GNOME Sharing.

[GlassOnTin]

Retitling to reflect where this actually stands. The EGFX work (this issue's original ask) landed in v5.24.69 and the Graphics Pipeline now negotiates cleanly against GRD — the "Client did not advertise support for the Graphics Pipeline" failure is gone.

The remaining blocker is different: GRD sends an RDP server-redirection PDU (MS-RDPBCGR §2.2.13.1 Server Redirection Packet) which Haven/IronRDP doesn't currently follow, so the session connects but renders a black screen. Scoping this issue to that redirect-follow work; the EGFX negotiation itself is considered done.

[GlassOnTin]

Progress: landed the server-redirection PDU parser (ac4b5db5) as the foundation for redirect-follow.

IronRDP 0.7/0.8 turned out to have no redirect parsing at all — the ServerRedirect (0xa) Share Control type falls through to "unexpected share control PDU type", which is exactly why the session breaks to a black screen. So step one was implementing RDP_SERVER_REDIRECTION_PACKET (MS-RDPBCGR §2.2.13.1.1) ourselves — fixed header + the LB_* optional fields in wire order (cross-checked against FreeRDP redirection.c), surfacing the reconnect target, the LoadBalanceInfo routing token, and any redirected credentials. 9 unit tests, host-verified; it declines unknown flags and won't panic on malformed input.

Next (Phase 2): wire it into the session loop and do a transparent Rust-side reconnect — replay the routing token as the X.224 nego cookie (Cookie: msts=…) and reconnect to the target (GRD's handover is usually the same host). The connector already supports injecting the nego cookie via Config.request_data, and the reconnect stays inside the Rust session thread so the Kotlin/UI layer is untouched.

Verification gap (being honest): I can't reproduce the GRD redirect on my dev box — it runs SDDM, and GRD's redirect/handover is a GDM-integrated "Remote Login" feature (the user-share + headless daemons don't redirect). So Phase 2 will need a GDM/GRD target to verify end-to-end before it ships. @agevlakh — I'll ping you for a focused retest on your Fedora setup once the reconnect is wired up; no need to do anything yet.

[GlassOnTin]

Progress on the redirect (on main, will be in the next build — not released yet).

Recap of where this stands: the EGFX negotiation that was the original ask shipped back in v5.24.69, so GRD gets past caps-exchange. The residual black screen is the server-redirection PDU GRD sends to hand the connection off — Haven/IronRDP didn't recognise it, so the session just died. IronRDP has no redirect support at all: a redirect decodes as pduType = PDUTYPE_SERVER_REDIR_PKT (0xA), which its ShareControlPdu::from_type() rejects as "unexpected share control PDU type". Haven then hit its generic error branch and broke the session — a black screen with nothing useful in the log.

What changed now: I've wired the redirection parser into the session loop. When that PDU arrives, Haven now recognises it straight from the raw X.224/MCS frame, pulls out the redirect target, and ends the session with a precise reason — "Server requested a session redirection to <target>; Haven does not yet follow RDP server redirection (see #117)" — instead of a silent black screen. The detection is gated strictly on the 0xA PDU type, so ordinary connections are provably unaffected.

Being straight about what this is and isn't: it does not yet make GRD render. It turns the mystery black screen into an accurate diagnosis, and it's the groundwork the actual fix builds on. It's covered by unit tests — including a round-trip through IronRDP's real MCS decoder — but I have not been able to verify it against a live GRD server, because my dev box runs SDDM and GRD's redirect/handover is GDM-integrated.

The remaining step — actually following the redirect (reconnecting with the routing token) — I've deliberately deferred rather than ship on guesswork. Two wire details decide whether it works, and I can't pin either down without seeing a real GRD redirect on the wire:

1. Whether GRD's LoadBalanceInfo field arrives already framed as Cookie: msts=…\r\n or as the bare token value — IronRDP's routing-token encoder re-adds that prefix, so replaying it verbatim would double-wrap it and the reconnect would fail.
2. Whether a pad byte-pair sits between the Share Control header and the redirection body.

Getting either wrong produces a silent reconnect failure that looks identical to the current bug, so I'd rather build it against a real capture than reason it out and iterate blind.

That's where you (or anyone here on GDM-based GRD — Fedora, Ubuntu GNOME) could unblock it fast: if you can reproduce the redirect and grab either a tcpdump/Wireshark capture of the RDP connection or an xfreerdp3 run at /log-level:TRACE, that would show the exact LoadBalanceInfo framing and let me finish the reconnect with confidence. @agevlakh — your Fedora GRD setup from #109 is the ideal repro if you're up for it. No rush; the detection lands in the next build regardless.

[MrTomiCZ]

Hi, @GlassOnTin I have the redirect issue:

How can I help?

[GlassOnTin]

Perfect timing — you can help with exactly the thing this issue is stuck on.

Your screenshot already tells me two useful things. First, Haven's redirect detection is working against your server (that precise error is it firing). Second, the wording "another session on the same host" is the fallback for a redirect that names no target address — so your GNOME Remote Desktop is doing the same-endpoint handoff, carried entirely by a routing token and one-time credentials. That's the variant the reconnect logic needs to understand, and until now I had no real capture of it.

Three things, in increasing order of value:

1. Your setup: which distro + GNOME version, and which sharing mode is enabled — Settings → Sharing → Desktop Sharing (mirrors your logged-in session) or Remote Login (headless / login-screen)? The redirect usually comes from the second one.

2. Server-side log during one failed connection attempt, both variants:

   journalctl -u gnome-remote-desktop -f
   journalctl --user -u gnome-remote-desktop -f
   

   The lines around "Sending server redirection" show what GRD thinks it's handing off to.

3. The capture that unblocks the implementation: I've just landed a diagnostic that logs the redirect packet's parsed structure (which fields your GRD populates, and the routing token the reconnect must replay). It will be in the next release — I'll ping here when it's out. Then, with your phone connected over adb:

   adb logcat -s RdpNative | grep '#117'
   

   and reproduce the failure once. Privacy note: that line includes the redirect's routing token (valid only for that one session) and the length of the one-time password — never the password itself, and none of your real credentials.

With those in hand, the follow step becomes implementable against your real wire data instead of guessed framing. Thanks for stepping up.