freerdp_client_settings_parse_command_line_arguments_ex allows supplying
user defined options to be parsed with the default ones from
client/common.
A callback must be implemented to handle the supplied arguments.
The mouse cursor channel enables remoting of the mouse cursor (bitmap)
over a DVC. The main use case is UDP, as only virtual channels can be
transported via UDP in RDP.
With the location channel, an RDP server can redirect the location of
the user from the client side to the server side.
The PDUs are almost the same as in the documentation, except for the
encoded types, these ones are here already parsed.
Optional values are accessed via pointers. If the pointer of a value is
NULL, then that value was not supplied by the client side.
Some virtual channels, like the location channel use encoded types to
lower the bandwidth usage.
Add common helper functions, so that each virtual channel doesn't have
to reimplement the parser functions again and again.
Under windows you can connect to a child session by requesting a named pipe to
the local server, and then do some RDP on this named pipe.
The protocol is like for /vmconnect with CredSSP, then Nego and then the "normal"
workflow for a connection. For CredSSP we force the usage of NTLM for the Negociate
SSPI, and the credentials are empty.
This patch moves the ARM configuration before starting the connection process, so
that we can do some provisioning of the FreeRDP settings with the items retrieved
from Azure.
Most notably that allows us to connect directly using RDSTLS security.
Some windows APIs do put \r\n every 64 characters of the output of a
base64 encoded blob. The extended version of crypto_base64_encode allows
to do the same.
C requires prototypes or compilers will complain about them missing. Our
library entry points do not have such, therefore add the macro
FREERDP_ENTRY_POINT which declares the function prototype automatically
before the function.
All clients can implement their own callbacks for
certificate/credential/smartcard/... but there is a common (default)
implementation for all clients.
with the new setting FreeRDP_UseCommonStdioCallbacks it is now possible
to force these over the client implementation provided ones
The AAD and AVD authentication mechanisms both need an OAuth2 token.
They only differ in the provided arguments, so unify the callbacks into
a single one with variable argument lists.
- Move responsibility for obtaining access tokens to clients
- Add function for getting access tokens for AVD
- Get correct server hostname during AVD setup
- Add utility function for doing http requests
The purpose of clipboard data locking is to make the other peer
retaining the current file list until a pending paste operation is done,
even though the clipboard selection changed.
As it may be difficult to determine, when a lock is needed, imitate the
same behaviour as mstsc:
When the server side supports clipboard data locking, always attempt to
lock the file list on the server regardless of what is advertised in a
FormatList PDU.
The Lock Clipboard Data PDU can even be already sent, before the
Format List Response PDU is sent.
This is also what mstsc, does: First, lock the new (potential) file
list, then unlock the file list, when the pending paste operation is
done.
So, rework the current clipboard implementation in that direction.
Since the implementation for timeouts for old file lists is a bit hard,
for now always force unlock pending locks, when the selection changes.
However, timeouts for old file lists can still be added in the future.
The reworked clipboard handling is done with the help of three hash
tables:
1. The inode table: This hash table manages all inodes for each file.
The keys in this table are the inodes themselves, while the values
the files and directories and their attributes (file size, last write
time, etc.).
2. The clipdata table: This table manages the locks for each file list.
The keys in this table represent the clip data id and the values the
clip data entries, which have a reference to the clip data dir, a
directory containing the whole selection, and some helper attributes,
like the clip data id itself.
3. The request table: Every file size or file range request is managed
here. When a FileContentsRequest is made, its stream id with the
respective details are added to this table. When a response is
received, these details can then be easily looked up here.
This PR creates a new /gateway:type:arm transport.
It depends on CJSON
The arm transport is not a transport by itself but is responsible
for getting the websocket endpoint from a configuration url derived from
the configured gateway host in the rdpw file or cmdline
* factor out most websocket specific code parts into websocket.c
* create wst.c (Websocket Transport) as gateway transport implementation
* introduce GatewayUrl setting that holds the websocket url
* introduce GatewayHttpExtAuthBearer that holds the HTTP Bearer
* GatewayHttpExtAuthBearer can be used by both rdg and wst
Implement a (optional) peer limitation check for shadow server.
with the command line option /max-connections:<number> the maximum
number of simultaneous connections can be limited.
the new (optional) callback CheckPeerAcceptRestrictions is used to check
for server implementation specific connection requirements before
accepting a client.
Optionally build the SDL client with Qt WebEngine to create a popup
browser for authentication to AAD. Also change the URL output on the
command line to use the "nativeclient" redirect for easier copy/pasting
of the authorization code.
The current server side channel handling of AUDIO_INPUT is currently
very constrained:
- Server implementations cannot measure the clients uplink, since the
Incoming Data PDU is currently unhandled and FreeRDPs DSP handling
delays the callback call of ReceiveSamples
- Servers currently cannot prefer a different protocol version
- Servers currently cannot change the used format
To solve these issues without running into the risk that some
simplifications constraint certain API usage, rework the current channel
handling to be very close to the documentation.
This means, that all documented API calls can be made by server
implementations and all documented PDUs, that the server side is
expected to receive are just parsed inside FreeRDP and then forwarded to
the API implementation.
* move type definition to WinPR as used there too.
* supported keyboard types are defined in
[MS-RDPBCGR] 2.2.1.3.2 Client Core Data (TS_UD_CS_CORE)]
use a enum instead of magic numbers to make code more readable.
The attributes xPos and yPos for a Color Pointer Update are confusing,
as they may be confused with the xPos and yPos of the pointer bitmap on
the actual screen.
Rename these attributes to what they actually represent, and that is the
hotspot position.
xPos and yPos are still members of the hotspot. However, hotSpotX and
hotSpotY are much more clearer.
In addition to that, the Large Pointer Update uses the same names for
the hotspot coordinates.
Currently, FreeRDP-based server implementations can do connect-time
autodetection.
However, without having any control over it.
In order to be able to override the default connect-time autodetection
handling, introduce three new states for the state machine of the
connection sequence and two new callbacks for the autodetect handling.
These are:
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_BEGIN
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_IN_PROGRESS
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_END
- OnConnectTimeAutoDetectBegin()
- OnConnectTimeAutoDetectProgress()
The END state is pretty simple: When the autodetection is finished and
the autodetect state is FREERDP_AUTODETECT_STATE_COMPLETE, transition
into the next state of the connection sequence.
The BEGIN state is entered, when capability-wise network autodetection
is available.
In this state, the OnConnectTimeAutoDetectBegin callback is called, the
server implementation may initialize any related handling here.
If the server implementation determines, that no further handling is
required, it can end the autodetection phase by returning
FREERDP_AUTODETECT_STATE_COMPLETE.
If not, and an autodetection request is sent, it returns
FREERDP_AUTODETECT_STATE_REQUEST.
The state machine of the connection sequence will then switch into the
IN_PROGRESS state.
In the IN_PROGRESS state, any incoming PDU is handled first, then the
OnConnectTimeAutoDetectProgress callback is called.
Like in the BEGIN state, the return value will determine, whether the
state machine of the connection sequence goes into the END state or goes
into (or rather stays) in the IN_PROGRESS state.
The current state of the autodetect API for the server side does not
include all allowed scenarios where the network autodetection can be
used.
This for example includes the connect-time autodetection, as the
related calls are hidden inside FreeRDP, and not exposed as public API.
In order to avoid duplicate send methods, check the state of the
connection sequence.
If the connection sequence is not yet done, use the connect-time request
types.
Otherwise, use the continuous request types.
The Bandwidth Measure Payload PDU is a little special case, as it is
only allowed to be sent during the connection sequence.
To ensure this, add an assertion in its sending method.
Also fix the handling for the Network Characteristics Sync PDU:
Previously, after parsing the PDU data, the read data was just sent
again to the client, which is wrong.
To fix this issue, introduce a callback for this client-to-server PDU,
so that the actual server implementation can hook up its own handling
for this PDU.
Depending on the situation, the server side may want to discard or use
the retrieved data here.
Moreover, decouple the send-handling for the Network Characteristics
Result PDU from the local autodetect variables.
Currently, these variables are shared between the send and receive
methods.
This leads to access problems, where the server side, wants to use a
different thread to send the autodetect PDU, as the receive handler may
receive an autodetect PDU and overwrite these values with possible
nonsense values.
This is especially the case with RTT response PDUs, as the written
netCharAverageRTT and netCharBaseRTT values are only correct, when only
one RTTRequest happens at a time and no stray RTTResponses are received.
TargetCertificate option is set in TARGET_CERTIFICATE_CONTAINER format.
Exposed ELEMENT_TYPE_CERTIFICATE and ENCODING_TYPE_ASN1_DER1 to allow
building it externally in the mentioned format.
Progressive codec was not honoring the threading flags in settings like does
remoteFX, so even when no multiple threads decoding was asked, progressive was
using multiple threads anyway. This patch fixes it.
