Server side we often see "FreeRDP_ChannelDefArray::len expected to be >= 31,
but have XXX", where XXX is lower than 31.
This patche fixes that, the old code was setting the size of ChannelDefArray to the
number of ChannelCount, which is usually not what we want. We want to keep it to 31
and have ChannelCount indicate how many of these channels are used.
To simplify building external channels and other plugins related
paths are now exported in the pkg-config file and the cmake package.
The paths can be used to install channels/plugins/extensions in
the configured search paths.
For pkg-config the following variables are now available:
* datadir
* plugindir
* proxy_plugindir
* extensiondir
They can be queried like: `pkg-config freerdp3 --variable plugindir`
The cmake package has three new variables that can be used:
* FreeRDP_PLUGIN_DIR
* FreeRDP_PROXY_PLUGIN_DIR
* FreeRDP_EXTENSION_DIR
Note: Depending on the build the directories are not necessarily created.
* unify reading of domain and username strings with all the checks
* add handling of (undocumented) padding in [MS-RDPBCGR]
2.2.10.1.1.2 Logon Info Version 2 (TS_LOGON_INFO_VERSION_2)
occurring with windows 11
* 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.
WinPR provides APIs to convert between keycodes between virtual
keycodes.
These keycodes can currently be evdev keycodes or Apple keycodes.
The evdev handling, however, handles XKB keycodes and not evdev ones.
The main difference between these is that XKB keycodes are shifted by
the value 8, compared to evdev keycodes.
In order to fix this situation, rename the evdev keycodes to XKB ones,
and introduce additionally a new keycode evdev, including its handling
for this keycode type.
Commit 2de7a4c249 introduced major changes
in the gateway authentication code. One of these changes was to decouple
NTLM specific authentication from the gateway code.
However with these changes, gateway authenciation with the old RPC code
stopped working and returned an authentication error. The problem is
that currently `credssp_auth_encrypt` encrypts the given message along
creating a signature.
The old code prevented encryption of the message by specifying
`SECBUFFER_READONLY` on the message buffer. The native Windows SSPI then
leaves this buffer as-is and gateway authentication works again.
This fix only applies to Windows platforms using the native SSPI API.
Interestingly this works on other platforms using the WinPR SSPI so
there seems to be a difference between the implementations (but that's a
topic for another PR).
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.
rts_read_common_pdu_header is used to determine if the packet was read
successfully. In that case it might fail but there should be no logging
done to not spam it with unnecessary warnings.
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.
