Skip to content

fix(connector): stay in CapabilitiesExchange when activation handles DeactivateAll#1371

Open
Rocco De Angelis (rdeangel) wants to merge 1 commit into
Devolutions:masterfrom
rdeangel:fix/connector-capabilities-exchange-same-state
Open

fix(connector): stay in CapabilitiesExchange when activation handles DeactivateAll#1371
Rocco De Angelis (rdeangel) wants to merge 1 commit into
Devolutions:masterfrom
rdeangel:fix/connector-capabilities-exchange-same-state

Conversation

@rdeangel

Copy link
Copy Markdown

Fixes #1362

Problem

#1254 taught the inner ConnectionActivationSequence to skip a Server Deactivate All PDU received before Server Demand Active (sent by e.g. Windows Server and gnome-remote-desktop as part of a Deactivation-Reactivation Sequence, MS-RDPBCGR 1.3.1.3): it returns Written::Nothing and remains in CapabilitiesExchange.

However, the outer ClientConnector::step() only accepts ConnectionFinalization as the resulting inner state after calling connection_activation.step(), so the same scenario still fails with invalid state (this is a bug) when it happens during the initial connection sequence — exactly the symptom reported in #1362.

Changes

  • Add the missing match arm in ClientConnector::step(): when the inner sequence stays in CapabilitiesExchange, the outer connector stays in CapabilitiesExchange too and waits for the next input.
  • Add a regression test mirroring the existing fix(connector): handle ServerDeactivateAll during CapabilitiesExchange #1254 tests, driving the outer ClientConnector instead of the inner sequence (fails with invalid state before the fix).

🤖 Generated with Claude Code

…DeactivateAll

PR Devolutions#1254 taught the inner ConnectionActivationSequence to skip a
Server Deactivate All PDU received before Server Demand Active (sent
by e.g. Windows Server and gnome-remote-desktop during a
Deactivation-Reactivation Sequence, MS-RDPBCGR 1.3.1.3): it returns
Written::Nothing and stays in CapabilitiesExchange. However, the outer
ClientConnector::step() only accepted ConnectionFinalization as the
resulting inner state, so the same scenario still failed with
"invalid state (this is a bug)" during the initial connection
sequence. Mirror the inner behavior in the outer state machine and
keep waiting for the Demand Active PDU.

Fixes Devolutions#1362

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Invalid state error using gnome-remote-desktop

1 participant