Protocol violations against [MS-RDPEDISP] in dynamic resizing code
Commit f506b8a3 added support for dynamic resizing.
First of all, I want to clarify the situation regarding the following part in the aforementioned commit, quoting:
This asynchronous checking is needed as we don't know whether the channel will
be connected or when. It is usually connected several seconds after
the remote desktop is already connected and shown.
The display update channel is opened by the server side. The open
operation is then, in case the client supports that channel, confirmed by the client via the respective DRDYNVC PDU or "denied" for any other case (see 2.2.2.2 DVC Create Response PDU (DYNVC_CREATE_RSP)
in [MS-RDPEDYC]
for details).
FreeRDP simplifies a lot of stuff for FreeRDP-based clients, so I don't know how that "client supports that channel" part is handled. It may be the case, that it is always confirmed, when the DISP DVC was added via freerdp_client_add_dynamic_channel
.
Regarding the when
in that commit: The display update virtual channel is a dynamic virtual channel (DVC). It can be opened and closed any time during the connection.
It can be closed by any peer, but only opened by the server side (only the server side can open DVCs).
Now to the protocol violation:
The underlying protocol documentation for the display update virtual channel extension is [MS-RDPEDISP]
. In section 1.3 Protocol Overview (Synopsis)
, the process of that channel is visualized.
First, the server side sends the caps PDU. And then the client is allowed to send new monitor layouts, while all sent layouts MUST maintain the monitor contraints of that protocol (see 2.2.2.2.1 DISPLAYCONTROL_MONITOR_LAYOUT
regarding this) and the constraints sent by the server in the caps PDU (2.2.2.1 DISPLAYCONTROL_CAPS_PDU
).
Currently, gtk-frdp appears to ignore the caps PDU and the monitor constraints in 2.2.2.2.1 DISPLAYCONTROL_MONITOR_LAYOUT
.
CC: @mkasik