Currently the proxy's TLS fallback if an NLA connection attempt failed
is broken. There are two issues with the current code that this PR
fixes:
- freerdp_reconnect is used which requires an already established
connection to work correctly. This is not the case since the NLA
connectin attempt failed. This resulted in a seemingly working TLS
connection but i.e. channels where missing/not working.
- The fallback connection attempt just altered the NLA security setting
in the instance's settings. However these settings have been already
modified by the NLA connection attempt so we need to create a copy of
the original connection settings before doing the first connect.
The PR also introduces freerdp_reset_context which restores the initial
connection settings for the given instance.
__LINE__ is not particularily well defined (most fall back to int).
We want to ensure that all the uses in a format string match the format
specifier, so do an explicit cast
This patch introduce the basic architecture to intercept content of dynamic
channel. When a dynamic channel is in intercept mode, we accumulate and reassemble
the current packet so that it can be passed for inspection.
When some channels are filtered, some misalignement of channel ids could happen.
This patch keeps track of the back and front channel ids to correctly identify a
channel and send packets with the correct channel id.
Previously smartcard authentication was only supported with TLS
connections so the proxy forced that security mode.
Since we now have a working NLA smartcard auth implementation we can
remove that code and leave the correct configuration to the proxy user.
The cmd parameter (type int) has been logged using the %s format
specifier causing an access violation.
Fixed by using get_packet_type to convert cmd to a string.
* Fixed format strings to match arguments
Reviewed and replaced all %d specifiers to match proper type
* Added proxy dynamic channel command type to log messages.
During tests I sometimes received DATA_FIRST_PDUs that were not part of
a fragmented message but contained a complete PDU.
The documentation is not quite clear about if this is a possible
scenario or a protocol violation. However in the description of the Data
field it says:
If the sum of the DVC header size and the value specified by the Length
field is less than 1600 bytes, then the actual data length equals the
value specified by the Length field.
This hints that DATA_FIRST_PDU might also contain complete Data and does
not necessarily mean to be the first part of a fragmented PDU.
Only the least significant bit is valid in the unicode flag UINT32. Some
clients send garbage data in the other bits which caused the proxy to
drop the connection which is wrong.
