dynamic channels can be opened at any time during a session. If we
receive a CREATE_REQUEST_PDU and the channel id is already in use, print
out a warning with the existing channel details and discard it before
creating the newly requested channel.
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 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.
* Use new enum constants with WINPR_KEYBOARD_* prefix
* Fix mapping of keycodes and scancodes, the offset of 8 is no longer
required if the proper keyboard type is used.
CertificateContent and PrivateKeyContent now have two valid formats:
It can be in format PEM (multiple lines) or a single line base64 encoded
PEM.
The first format is preferrable in case the pf_config* API is used to
set the certificate/key, the latter in case an actual config file is in
use where multiline configuration data can not be directly entered.
* 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.
The decoded base64 data might contain PEM with/without/with multiple
'\0' at the end of the string. We do not want to drag this through our
code so ensure the length matches the string length including '\0'
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 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
The shadow server tries to resize the client to use a compatible
resolution. If that fails, e.g. if there is another resize request after
the disconnect/reconnect sequence, abort the connection.
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.
* Use new ConvertUtf8ToWChar, ConvertUtf8NToWChar,
ConvertUtf8ToWCharAlloc and ConvertUtf8NToWCharAlloc
* Use new ConvertWCharToUtf8, ConvertWCharNToUtf8,
ConvertWCharToUtf8Alloc and ConvertWCharNToUtf8Alloc
* Use new Stream UTF16 to/from UTF8 read/write functions
* Use new settings UTF16 to/from UTF8 read/write functions
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.
* xfreerdp: fix typo in logs
* winpr: file appender, small code cleanup
* shadow-server: add an option for TLS secrets
This allows to dissect connections to the shadow server.
The shadow server was setting up the dynamic channel too quickly, leading
to unexpected packets during the negotiation (unexpected licence packet error
message on the client side). So let's starts dynamic channel once the activation is
done.
* add support for 64-bit big-endian encoding
* kerberos: drop reliance on gssapi and add user 2 user support
* Fix local variable declared in the middle of the function body
* kerberos: add ccache server option
Co-authored-by: fifthdegree <fifthdegree@protonmail.com>
Co-authored-by: David Fort <contact@hardening-consulting.com>
This big patch fixes fragmentation handling in the dynamic channel. We used to
have a single state to handle fragmentation at the main dynamic channel level, but
in fact packets can be fragmented per sub channel. So we have to maintain a fragmentation
state per sub channel, this involve treating dynamic and static channels differentely
(so the size of the patch that has to implement state tracking per dynamic channels).
This adds a User, Domain and Password parameter in the Target section of the configuration
to specify and use a fixed backend user, domain or password (overriding the one
passed by the front user).
akallabeth