Surface the actual Share Control PDU type when 'unexpected Share Control Pdu' fires

[GlassOnTin]

Problem

When ironrdp receives a Share Control PDU during Capabilities Exchange that isn't ServerDemandActive, the user-facing error is:

RDP connect finalize failed: Error { context: \"unexpected Share Control Pdu (expected ServerDemandActive)\", kind: General, source: None }

The actual PDU type that was received isn't included in the error string. From a downstream client's perspective (Haven, in this case) this means we can't distinguish between, e.g.:

• Server sent a SetErrorInfo PDU rejecting the session for a specific reason (the most informative case — that PDU has a numeric error code we'd want to surface)
• Server sent SaveSessionInfo or Server Auto-Reconnect Status instead of demand-active
• Server sent some other implementation-quirk PDU

Reported via

GlassHaven/Haven#109 — agevlakh's GNOME Remote Desktop on Fedora 44 hits this after CredSSP succeeds. We were able to characterise everything up to this point (TLS ✓, NLA ✓ now after a separate sspi-rs interop session) but the actual server response that ironrdp rejects is opaque.

Asks

1. Include the received PDU's discriminant (and, ideally for SetErrorInfo, the error code value) in the context string when raising this error. Even just unexpected Share Control Pdu (got SetErrorInfo, expected ServerDemandActive) would let us trace it back to MS-RDPBCGR §2.2.5.1 and explain the failure to users.
2. Optionally a structured variant of ConnectorErrorKind for "server rejected at capabilities phase" so downstream code can map to a friendlier message instead of substring-sniffing the Reason string.

Happy to PR if you'd like — would be a small change in crates/ironrdp-connector/src/connection_activation.rs (or wherever the demand-active wait is checked).

[CBenoit]

I acknowledge the pain point, although I didn’t reread carefully the current code to verify what would be the best approach. At this point feel free to open a PR so we can see how it turns there.

[GlassOnTin]

Following up on this — the Haven user with the GRD interop bug (Haven#109) ran journalctl on the GRD side. It's exactly the EGFX requirement:

gnome-remote-desktop-daemon[792]: [RDP] Client did not advertise support 
  for the Graphics Pipeline, closing connection
[ERROR][com.freerdp.api] - [rdp_peer_handle_state_demand_active]: 
  [CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE] 
  freerdp_peer::Capabilities() callback failed

GRD aborts before sending ServerDemandActive, so the client's "unexpected Share Control PDU" error string is technically accurate but actively misleading — there's no PDU at all, the channel just closed during caps validation.

Two takeaways for IronRDP regardless of where the EGFX implementation lands:

1. Detecting the early-close case before parsing: when the server closes the TCP connection during/after confirmActive without any data, surfacing "server closed during capabilities exchange (peer may require EGFX or another mandatory capability)" would be far more actionable than "unexpected Share Control PDU" pointing at whatever bytes happened to be in the buffer.

2. The PDU-type ask in this issue still stands for the case where a server does send an unexpected PDU after caps — but the GRD case specifically is a clean close, not a wrong PDU, so the diagnosis improves further if those two error paths are distinguished.

Filed as a Haven roadmap item (Haven#TBA) — interest in EGFX-as-client landing in ironrdp-session upstream from your end? It'd benefit any IronRDP-based client targeting modern Linux RDP servers.

[glamberson]

Concur on both takeaways, particularly the distinction between "server closed during caps exchange" and "server sent a wrong PDU after caps". These are different failure modes from the user's point of view and conflating them under one error string sends people debugging in the wrong direction. See related comment on #1237 for how the GRD case is also driven by the missing SUPPORT_DYN_VC_GFX_PROTOCOL cap flag, which closes the loop on the specific GRD interop path even if the diagnostic improvement here remains valuable on its own.