Now using nCount as in and out argument.
When called, set nCount to the number of available handles.
This value is checked and an error returned, if not enough
handles are available.
* Though not frequent, it's possible to get TsProxySetupReceivePipe
data of stublength 4 that is actual data. This happens when
header->common.call_id == rpc->PipeCallId &&
!(header->common.pfc_flags & PFC_LAST_FRAG).
This should address GW disconnects that manifest as SSL read errors.
This is a fix for #2399: when there's no variants we should not try to scan them.
I have set the RDP US keyboard for the South African layout, if someone has a better
layout...
Note: we should probably set something that is not zero for other layouts
Change the return type of Stream_Ensure*Capacity from void to BOOL to be
able to detect realloc problems easily. Otherwise the only way to detect
this was to check if the capacity after the call was >= the required
size.
In case Stream_Ensure*Capacity fails the old memory is still available
and need to freed outside.
This commit also adds checks to most calls of Stream_Ensure*Capacity to
check if the call was successful.
Microsoft iOS Remote Desktop Clients eventually send NULL-terminated
hostnames in SNI which is not allowed in the OpenSSL implementation.
Since we're not using SNI this commit adds an OpenSSL TLS extension
debug callback which modifies the SSL context in a way preventing it
from parsing this extension
The X.224 Connection Request PDU might contain an optional cookie or
routing token before the optional RDP Negotiation Request (rdpNegReq).
If present, both of these fields must be terminated by a 0x0D0A
two-byte sequence. It seems that until now FreeRDP has incorrectly
assumed that a token or cookie must always be present.
If that was not the case, FreeRDP was searching for 0x0D0A until it
arrived at the end of the stream which prevented the remaining data
(RDP Negotiation Request, RDP Correlation Info) from being parsed.
tls_disconnect shut down the ssl stream but didn't inform
the BIO(s) about this therefore could happen that a second shut down
was initiated (e.g. in bio_rdp_tls_free) causing rather long delays.
After removing the shut down from tls_disconnect the only thing the
function does is to prepare/send an alert therefore it was renamed to
tls_send_alert.
