contrary to '[MS-RDPBCGR] 1.3.9 Connect-Time and Continuous Network
Characteristics Detection' we have seen autodetection reqeusts mixed in
between licensing messages. This relaxes the state machine and allows
handling.
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.
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 client tries to connect using RDSTLS only when it has received a
server redirection PDU with LB_PASSWORD_IS_ENCRYPTED flag.
The server exposes RDSTLS on negotiation if it has been configured on settings.
Then authenticates a client using configured credentials from settings:
RedirectionGuid, Username, Domain, Password.
most protocol internal caches do not need to be exposed. this reduces
the public API and allows us to more easily improve/change this during a
release cycle
* Remove duplications in rdpRsaKey, reuse rdpCertificate for public
components
* Move all private key and certificate code to certificate.c,
remove the tssk_* variables from gcc
* Handle update of client and server random keys in wrapping functions
* Simplify gcc_write_server_security_data, use certificate.c functions
to write the certificate data
* Refactor security_establish_keys, use the random values stored in
settings directly
With the latest client changes the internal event loop requires a handle
to wait on. Add a new function to (re)set the newly added transport event handle.
Up to this commit the client and server state machine handling used
different return values for state machine changes.
This is fixed with this commit:
* Use common enum return values
* Use common helper functions
The demand active state might be called when receiving data from the
client during initial connection phase or might be triggered server
side after sending a deactivate all pdu
