fix(rdpdr): defer User Logged On that arrives before Client ID Confirm

[AKolenda]

After the user logs in, Windows re-announces the RDPDR channel and sends Server User Logged On before the new Server Core Capability Request and Server Client ID Confirm. Rdpdr treated that order as a protocol error, so a connection to a Windows 11 host ended a few seconds after login with:

PDU error: [ironrdp_rdpdr::Rdpdr::handle_user_logged_on] other (received RDPDR user logged on before client ID confirmation)

Observed sequence (ironrdp_rdpdr=debug):

ServerAnnounceRequest   client_id: 3
ServerCoreCapabilityRequest
ServerClientIdConfirm   client_id: 3
ServerAnnounceRequest   client_id: 2
UserLoggedon                          <- previously fatal
ServerCoreCapabilityRequest
ServerClientIdConfirm   client_id: 2

Rdpdr now remembers a User Logged On that arrives before the Client ID Confirm and handles it right after the confirmation, so the backend's handle_user_logged_on and the post-logon device announcement still run once the client ID is known. A new Server Announce clears the pending flag. FreeRDP accepts the same order: its state check allows PAKID_CORE_USER_LOGGEDON before PAKID_CORE_CLIENTID_CONFIRM.

Validation

• New unit test user_logged_on_before_client_id_confirm_is_deferred: an early User Logged On yields no messages, the following Client ID Confirm announces the configured drive, and drive IRPs are dispatched afterwards.
• cargo test -p ironrdp-rdpdr, cargo clippy -p ironrdp-rdpdr --all-targets -- -D warnings, cargo fmt --check.
• Live run against the Windows 11 host that produced the error: the session stays connected past login, and the log shows the deferred logon being handled after the confirmation.

[Copilot]

Copilot review overview

🟡 Changes recommended

Add coverage for the backend callback and stale-state reset path.

Review effort: Lite
Findings: 1

Open (1)

• Test deferred logon invokes backend callback exactly once · New

What changed in this PR

Fixes RDPDR handling when User Logged On arrives before Client ID Confirm.

Changes:

• Defers early logon notifications until client confirmation.
• Resets pending state on new server announcements.
• Adds regression coverage for deferred device handling.

File	Summary
crates/​ironrdp-rdpdr/​src/​lib.rs	Implements deferred logon handling and tests the sequence.

[AKolenda]

Added in bc64c6a: TrackingBackend now counts handle_user_logged_on calls. The test asserts zero calls while the logon is deferred and exactly one after Client ID Confirm. A second test, server_announce_discards_a_deferred_user_logged_on, checks that a new Server Announce drops a pending logon (no backend call, no post-logon announcement). I checked that each test fails if the corresponding line in the fix is removed.

[Benoît Cortier (CBenoit)]

PR automation is failing because of a picky-krb 0.12.5 incompatibility, fixed on master by #2074. Please rebase on master to fix it.

Update: no rebase needed anymore. picky-krb 0.12.5 was yanked from crates.io (re-released as 0.13.0), so the API check builds again without changes to this branch. PR automation has been re-run here and passes.

[github-actions]

PR #2079 defers an RDPDR Server User Logged On that arrives before Server Client ID Confirm (as Windows 11 sends after re-announcing the channel) instead of terminating the connection with a PDU error. Verified in pr-head: a single user_logged_on_pending flag is set in handle_user_logged_on when client_id_confirmed is false, cleared on Server Announce in lockstep with the other sequence state, and consumed once via core::mem::take at the end of handle_client_id_confirm, so the backend callback and post-logon device announcements still run after confirmation. This matches MS-RDPEFS sequencing and the FreeRDP-precedent claim. Two new tests cover deferral and discard-on-reannounce, and the implementation is minimal with no compression concerns. The only valid specialist finding is a low-severity state/message coupling: within handle_client_id_confirm, device announcements are registered in pending_device_announcements and their messages built before the deferred backend handle_user_logge…

[github-actions]

[skeptical] Backend error during deferred User Logged On drops already-built device announcements — low 🟡 — The deferral folds User Logged On handling into the Client ID Confirm process() call. By the time the flushed backend.handle_user_logged_on runs, announce_devices has already registered the device IDs in pending_device_announcements and built the ClientDeviceListAnnounce messages. If the backend callback returns Err, the error propagates out of process() and the built messages are never returned to the transport, leaving pending_device_announcements stale relative to what the server actually received; the affected devices are never activated and re-announcing them later trips the announced-more-than-once check. Not a regression for the misordered flow (it was previously fatal) and requires a backend error at exactly this point; detaching the announcement messages before the flush or registering them only after the deferred call would avoid the coupling.

[github-actions]

🟢 PR #2079 is a minimal, well-scoped fix in crates/ironrdp-rdpdr/src/lib.rs: a Server User Logged On PDU arriving before Server Client ID Confirm no longer terminates the connection. Instead, a single user_logged_on_pending bool records the event; handle_client_id_confirm replays it via core::mem::take after setting client_id_confirmed = true, so the backend's handle_user_logged_on and post-logon device announcements run exactly once with the same semantics as the non-deferred path (the RDP51 post_logon_devices_announced guard in announce_post_logon_devices behaves identically). Resetting the flag in handle_server_announce is consistent with the existing full channel reset there, and Windows re-sends UserLoggedon per re-announce cycle, so no event is lost; repeated early PDUs coalesce harmlessly since the PDU is payload-free. All modified lines verified in pr-head: the field/init/reset, the deferred branch in handle_user_logged_on, the replay block in handle_client_id_confirm, and two t…