The sound and microphone redirection channels (and in part TSMF)
did not properly decouple encoding/decoding from the backends used
to play/record sound.
Encapsulating encoding/decoding in rewritten freerdp_dsp_* functions
with variable backends, simplifying alsa/oss/pulse/... audio backends.
issue detected by cppcheck
[channels/drive/client/drive_main.c:454] -> [channels/drive/client/drive_main.c:443]: (warning) Either the condition '!irp' is redundant or there is possible null pointer dereference: irp.
[client/X11/xf_window.c:582] -> [client/X11/xf_window.c:580]: (warning) Either the condition '!xfc' is redundant or there is possible null pointer dereference: xfc.
[winpr/libwinpr/path/test/TestPathShell.c:40] -> [winpr/libwinpr/path/test/TestPathShell.c:43]: (warning) Either the condition '!path' is redundant or there is possible null pointer dereference: path.
[winpr/libwinpr/path/test/TestPathShell.c:49] -> [winpr/libwinpr/path/test/TestPathShell.c:52]: (warning) Either the condition '!path' is redundant or there is possible null pointer dereference: path.
Implements the decoding of video streams using common H264 decoders. We also implement
a trivial feedback algorithm.
Sponsored by: Rangee GmbH (http://www.rangee.de)
The [MS-RDPESC] clearly states in section 2.2.2.18 that Status_Call's
cbAtrLen must not be used when generating Status_Return response. This
is also how FreeRDP 1.1 behaves.
My method was to find the LIBAVUTIL_VERSION_* at the commit where the
updated AV_ prefixed constants became available, add one "micro" version
to it, then if it's not at least that version, provide the unprefixed
constant. It just so happens that the same commit introduced all
the AV_* constants.
The AV_ prefixed constants have been available since
ffmpeg@def97856de6021965db86c25a732d78689bd6bb0 (2015-07-07), or version
2.8.
The non-prefixed constants are set to be removed in the next ffmpeg
release, and were removed in
ffmpeg@302554835e39b79b977ed60c9afe81b44590dfef (2016-12-05).
Since ec027bf dynamic resolution is broken when used with egfx. Before that commit
we were tracking a server sent resize by setting a DesktopResize callback. This callback
is called when the desktop is resized by the server. Anyway the problem was that when this
callback is called, the activation sequence is not always completed, which were leading to
some freeze with 2012r2 servers (sending packets before the sequence is finished).
So with the faulty commit, we are tracking server resizes by subscribing to the Actived
event, that is called at the end of a reactivation sequence, so we're sure to not send packets
when not fully activated.
Anyway the issue that shows on (#4330) is that when you use egfx, no reactivation sequence happens,
the server only sends a ResetGraphics message with the new size, and so we miss the resized event.
This fix introduces a new GraphicsReset event, makes the display channel subscribe to that event,
and react accordingly.
* fix StatusW_Call to rely and use SCardStatusW
* fix trace call in StatusW_Call - needs to be called after the sizes
are set
* unify SCardStatus functions for pcsc - let the internal function handle unicode directly
This fixes an issue with size calculations of SCardStatusW.
If the display channel is available we use it to allow the user to resize the
xfreerdp window. When the window is resized we announce a new monitor layout and
the server reacts by doing a reactivation sequence to the new size.
The minimum window size is limited to 300x300 as 2012 servers crash horribly
if we send them a smaller layout.
SCardAddReaderName isn't part of the SCard API.
Note: removing this also removes the possibility to redirect single
smartcard readers with /smartcard:READERNAME. However this features
wasn't implemented in a general way and will be re-added as part of
the smart card channel directly.
In case SCardGetStatusChange returned an error the call didn't return
any data but STATUS_NO_MEMORY as the calloc failed. This caused problems
with multiple applications server side (hangs and incorrect behavior).
Now the case when no readers are returned is handed correctly and the
data is also filled and send if the call fails.
The smart card channel tried to mimic mstsc's behavior on if an IRP was
processed synchronously or asynchronously. As the channel uses one thread per
context it could happen, especially with PCSC, that the main
channel thread was blocked waiting for an smart card operation to
complete. To prevent that behavior only call known safe functions in the
main thread (like CreateContext) and call the rest asynchronously.
For example the channel would block if a ListReaders is invoked on
the same context where a GetStatusChange (infinite timeout)
was already pending. Only when a status change happened the channel
would continue.
Note: Due to the one context per thread design it's important that
cancel isn't queued an alway run synchronously. Otherwise a specific
context might lock.
Device control calls always returned SCARD_S_SUCCESS even if an error
occurred. This caused server side software (including the card manager)
to behave incorrectly.
According to MS-RDPESC the smart card channel must set the IoStatus to
an NTSTATUS in case a encoding or decoding error happens. The smart card
channel did this correctly but the output stream was modified
incorrectly causing the smart card remote manager to stop in error
cases.
1. In connect_to_sshagent() if connect() fails, the socket agent_fd is
leaked. It needs to be closed before returning.
2. Fix copyright messages.
3. Make if statement with call to CreateThread() clearer to read.
Add the sshagent plugin to forward the ssh-agent protocol over an RDP
dynamic virtual channel, just as the normal ssh-agent forwards it over
an SSH channel. Add the "/ssh-agent" command line option to enable it.
Usage:
Run FreeRDP with the ssh-agent plugin enabled:
xfreerdp /ssh-agent ...
In the remote desktop session run xrdp-ssh-agent and evaluate the output
in the shell as for ssh-agent to set the required environment variables
(specifically $SSH_AUTH_SOCK):
eval "$(xrdp-ssh-agent -s)"
This is the same as for the normal ssh-agent. You would typically do
this in your Xsession or /etc/xrdp/startwm.sh.
Limitations:
1. Error checking and handling could be improved.
2. This is only tested on Linux and will only work on systems where
clients talk to the ssh-agent via Unix domain sockets. It won't
currently work on Windows but it could be ported.
Added some checks so that when setting a cache entry fails, we close connection (or
we fail later when trying to use that empty entry).
The small cache egfx capability has also been fixed.
If the server sends us garbage (or the client provides it) then it is
possible for the multiplication to overflow (as it is performed on
unsigned 32-bit values) which will result in a false positive failure of
the sanity check. Avoid it by rearranging arithmetics a little.
Keep the multiplication in the error message because we are interested
in the number of bytes in the stream and how it compares to the number
we have expected based on the presumed file count.
[channels/tsmf/client/tsmf_main.c:89] -> [channels/tsmf/client/tsmf_main.c:95]: (warning) Either the condition '!callback' is redundant or there is possible null pointer dereference: callback.
[channels/urbdrc/client/libusb/libusb_udevice.c:1666] -> [channels/urbdrc/client/libusb/libusb_udevice.c:1661]: (warning) Either the condition 'request' is redundant or there is possible null pointer dereference: request.
[channels/drive/client/drive_file.c:125]: (error) Memory leak: path_slash
[server/Windows/wf_dxgi.c:195]: (error) Invalid number of character '(' when these macros are defined: 'WITH_DXGI_1_2'.
The file contents PDUs support 64-bit file sizes and offsets, but
MS-RDPECLIP explicitly says in 2.2.5.3 File Contents Request PDU that
file larger that 4 gigabytes are not supported by the server. It turns
out that the supported size is even lower than that. The server cannot
correctly handle files larger than 2 gigabytes (inclusive). When faced
with such files it correctly retireves the lower part, but fails to
accept any data past that boundary. After receiving a file range reply
the server repeats the file range request with the same offset, and
again, and again, and again, making no progress and blocking the file
transfer indefinitely. This is not the behavior we would like to have.
Microsoft support site acknowledges and documents the issue [1],
suggesting the users to use disk drive redirection instead to transfer
large files. (File transfers via cliprdr are considerably slower than
disk drive redirection so the suggestion makes very much sense.)
However, we would like to avoid the lockdown of the remote session if
the user does attempt to transfer such files so we add a size check.
Putting it into the conversion from FILEDESCRIPTOR to CLIPRDR_FILELIST
is not an ideal place (the clients may not use the common utilities),
but that's good enough currently.
[1]: https://support.microsoft.com/en-us/help/2258090
Do not try to 'helpfully' fixup the length of the data provided by the
client when FILECONTENTS_SIZE is present. This can lead to a crash if
the client wants to report an error in msgFlags, sets cbRequested to
zero, and does not provide any data in requestedData. For example,
XFreeRDP does this in xf_cliprdr_send_file_contents_failure() and
xf_cliprdr_clipboard_file_size_failure().
clipDataId is an optional field of CLIPRDR_FILECONTENTS_REQUEST.
The client should not send it to the server without sending a prior
CLIPRDR_LOCK_CLIPDATA request. The reverse is true as well: the
server should not include these additional 4 bytes without locking
the file in question.
The value zero is a valid ID, it cannot be used as a sentinel value.
Introduce a separate flag to tell whether the clipDataId has been set
and can be relied upon.
Also fix formatting. These stupid line breaks have negative impact on
readability, and the lines do fit into the 100 column limit either way.
The format is described in MS-RDPECLIP 2.2.5.2.3 Packed File List
(CLIPRDR_FILELIST). These functions handle conversion between the
on-the-wire data from cliprdr and arrays of FILEDESCRIPTOR structs.
FILETIME handling is a bit wacky, but that's what we currently have.
