REDIRECTION_VERSION6 breaks redirection for currently unknown reasons.
Revert to the last known good version until we receive an update on
documentation for the redirection handling
* Added missing definitions for RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN
and RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED flags
* Updated stringification functions for these flags
* Implemented client and server EarlyCapabilityFlags filter for
these flags as FreeRDP currently does not implement them.
When using Enhanced RAIL the HandshakeEx flag must also be set. However
in the current code it was always overwritten by the server flags (which
might lack the flag).
The length had more bytes than the RDP_SERVER_REDIRECTION_PACKET
structure because it was counting bytes before the struct.
Using a start variable from the beginnig of sending the structure fixes
it.
When a FreeRDP-based server tried to open a DVC, but the client answered
the DVC create request with a negative CreationStatus in the DVC create
response PDU, the server can then assume that no actual PDUs can be
received for that channel.
However, as long as the channel handle exists, FreeRDP happily forwards
any potential PDU for that handle disregarding the CreationStatus.
This is problematic, since the channel handling usually runs in its own
thread and as a result, the channel may not be destructed yet, when
receiving such stray PDU.
The PDU may be processed, even though it is not expected to be.
A situation, where this becomes problematic is the AUDIO_PLAYBACK_DVC
channel.
It may be the case, that the client answered the DVC create request
with a negative result, the server may try to close the handle and open
the static channel (RDPSND) instead, but before the server can close the
channel handle, the client actually sends PDUs regarding the format
negotiation.
In this case, the server may unintentionally already set things up,
which was not desired (the DVC is about to be closed anyway).
While this specific situation is hypothetical, since it would depend on
a malicious client, it is still possible to happen, especially since the
server implementation does not invoke the format negotiation, but
FreeRDP does it automatically, as soon as the DVC create request is
sent.
Fix this issue by discarding any data PDUs (DYNVC_DATA_FIRST and
DYNVC_DATA) of channels, that were not opened successfully.
With all calls when WTSVirtualChannelQuery returns FALSE that means that
no ppBuffer was allocated, that was not the case with class=WTSVirtualChannelReady.
Most callers were not aware of that, leading to leaks for example when the channel is
not available client-side, the patch changes that so that you have to call call WTSFreeMemory
only if WTSVirtualChannelQuery returned TRUE.
