Skip to content

server: reactivation drops interleaved virtual-channel PDUs #1512

Description

@uchouT

During server-initiated Deactivation-Reactivation, RdpServer gives the multiplexed inbound RDP stream to Acceptor while it waits for Confirm Active and Connection Finalization PDUs.

Other traffic may still be queued or in flight. Currently, PDUs unexpected to the current acceptor state can be silently discarded:

  • Framed::read_by_hint() consumes complete frames that do not match the current hint.
  • CapabilitiesWaitConfirm attempts to decode every MCS SendDataRequest payload as a Share Control PDU and drops decode failures during reactivation.
  • FinalizationSequence may discard such traffic, advance incorrectly, or fail the connection.

This was observed on qemu-rdp during resize with FreeRDP: before Confirm Active arrived, two frames on the negotiated drdynvc channel were classified as unexpected and stalled qemu-rdp.

A state-machine mismatch should be distinguished from malformed wire data. Non-activation traffic should be routed or deferred according to an explicit policy, and only the expected activation PDU should advance the sequence.

Related change: #630 .

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions