cache dependancies so we are not hitting github often
update android dependancies to latest and compile.
./android-build-freerdp.sh --ndk ~/Programming/android-ndk-r15c --relWithDebug --jpeg
Still an error compiling openh264
The async transport option is broken by design.
If used the main loop is called from the transport thread and the
main thread of the application.
Unless the transport layer is refactored to just work on queues
(input and output) this option will never work, therefore remove it.
Commit 54a7d799d1 introduced a problem
where /app was used instead of /shell causing a black screen when remote
programs were used. The Android client doesn't support remote apps
therefore /app can't work. "Remote program" just sets the selected
program as shell to run.
changed from int to long, however, the changed method signature was not
reflected in android_cliprdr.c.
As a result, a copy in the remote session would result in the
java.lang.NoSuchMethodError below:
01-08 20:24:16.620 8234 8865 E AndroidRuntime: FATAL EXCEPTION: Thread-11495
01-08 20:24:16.620 8234 8865 E AndroidRuntime: Process: com.iiordanov.aRDP, PID: 8234
01-08 20:24:16.620 8234 8865 E AndroidRuntime: java.lang.NoSuchMethodError: no static method "Lcom/freerdp/freerdpcore/services/LibFreeRDP;.OnRemoteClipboardChanged(ILjava/lang/String;)V"
01-08 20:51:44.737 11025 11439 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xa0 in tid 11439 (Thread-6)
01-08 20:53:14.887 11717 11717 E AndroidRuntime: FATAL EXCEPTION: main
This commit fixes the bug.
- fixed invalid, missing or additional arguments
- removed all type casts from arguments
- added missing (void*) typecasts for %p arguments
- use inttypes defines where appropriate
Global static variables do not work, if more than one instance
of an RDP client is running in the same process space.
Removed the varaibles where possible and replaced them with
thread local storage where necessary.
It would be good if we have a easy way to call aFreeRDP in another Android APP (Requirement also mentioned in #2720)
We can define a scheme (freerdp://) as unified way to launch FreeRDP from another APP or browser and connect to compatible RDP server
1. Define scheme freerdp://
2. General form could be freerdp://user@hostname:port/connect?key1=value&key2=-&key3=%2b&key4=
3. [user] part would be translated to /u:
4. [hostname:port] would be translated to /v:
5. The [user@hostname:port] part would be used as app title, currently it's just the progress dialog title
6. query parameters would be translated to command line arguments. Later same arguments will overwrite the formers:
a. key1=value: => /key1:value
b. key2=-: => -key2
c. key3=%2b => +key3 (%2b is url encoded +)
d. key4= => /key4
e. Especially, drive=sdcard will be properly handled with local sdcard path. On my device it will be translated to /drive:sdcard,/storage/emulated/0
Owing to the refactor work in PR #3097, we now pass same command line argument to JNI for freerdp settings.
We just need to make the SessionActivity accept freerdp scheme and translate argument from URI form to command line form.
After #3097, the java side pass command line argument to JNI for freerdp settings. However there's several issues need to be fixed:
1. The argument /sound should be appended if freerdp is required to play sound at local device
2. The option value for "audio-mode" is not correct.
It should match the definition in client/common/cmdline.c
/* Audio Mode */
define AUDIO_MODE_REDIRECT 0 /* Bring to this computer */
define AUDIO_MODE_PLAY_ON_SERVER 1 /* Leave at remote computer */
define AUDIO_MODE_NONE 2 /* Do not play */
3. Uncomment support for WAVE_FORMAT_PCM in audin. I tested on my android phone and Nokia N1 tablet. It works on both device
Certificates can now be accepted temporarily.
The callbacks for certificate validation have been
modified to extend the information presented to the user.
winsock.h pulls in a lot of defines and dependencies that are not
required and partially unwanted in winpr's core (for parts that are not
related to network). In order to get rid of this dependency and have an
independent defines for extended winpr functions the WINPR_FD_* defines
are used internally (and for exposed functions). Where required, like in
WSAEventSelect, the FD_* is mapped to WINPR_FD_*.
This patch contains:
* checks for malloc return value + treat callers;
* modified malloc() + ZeroMemory() to calloc();
* misc fixes of micro errors seen during the code audit:
** some invalid checks in gcc.c, also there were some possible
integer overflow. This is interesting because at the end the data are parsed
and freed directly, so it's a vulnerability in some kind of dead code (at least
useless);
** fixed usage of GetComputerNameExA with just one call, when 2 were used
in misc places. According to MSDN GetComputerNameA() is supposed to return
an error when called with NULL;
** there were a bug in the command line parsing of shadow;
** in freerdp_dynamic_channel_collection_add() the size of array was multiplied
by 4 instead of 2 on resize
* increase minimum required SDK to 14
* change functions from void to BOOL where required to have proper
return values
* update the JAVA classes and JNI accordingly
* add return value checks for *alloc and strdup
1)
Added missing checks for CreateEvent which also required the
following related changes:
- changed freerdp_context_new API to BOOL
- changed freerdp_peer_context_new API to BOOL
- changed pRdpClientNew callback to BOOL
- changed pContextNew callback to BOOL
- changed psPeerAccepted callback to BOOL
- changed psPeerContextNew callback to BOOL
2)
Fixed lots of missing alloc and error checks in the
changed code's neighbourhood.
3)
Check freerdp_client_codecs_prepare result to avoid segfaults
caused by using non-initialized codecs.
4)
Fixed deadlocks in x11 caused by missing xf_unlock_x11() calls
in some error handlers
5)
Some fixes in thread pool:
- DEFAULT_POOL assignment did not match TP_POOL definition
- don't free the pool pointer if it points to the static DEFAULT_POOL
- added error handling and cleanup in InitializeThreadpool
1. Don't draw to screen if server sends begin/end paint
messages without any real updates.
2. Redraw only summary region that covers really invalidated
part of screen.
[MS-RDPBCGR] Section 5.3 describes the encryption level and method values for
standard RDP security.
Looking at the current usage of these values in the FreeRDP code gives me
reason to believe that there is a certain lack of understanding of how these
values should be handled.
The encryption level is only configured on the server side in the "Encryption
Level" setting found in the Remote Desktop Session Host Configuration RDP-Tcp
properties dialog and this value is never transferred from the client to the
server over the wire.
The possible options are "None", "Low", "Client Compatible", "High" and
"FIPS Compliant". The client receices this value in the Server Security Data
block (TS_UD_SC_SEC1), probably only for informational purposes and maybe to
give the client the possibility to verify if the server's decision for the
encryption method confirms to the server's encryption level.
The possible encryption methods are "NONE", "40BIT", "56BIT", "128BIT" and
"FIPS" and the RDP client advertises the ones it supports to the server in the
Client Security Data block (TS_UD_CS_SEC).
The server's configured encryption level value restricts the possible final
encryption method.
Something that I was not able to find in the documentation is the priority
level of the individual encryption methods based on which the server makes its
final method decision if there are several options.
My analysis with Windows Servers reveiled that the order is 128, 56, 40, FIPS.
The server only chooses FIPS if the level is "FIPS Comliant" or if it is the
only method advertised by the client.
Bottom line:
* FreeRDP's client side does not need to set settings->EncryptionLevel
(which was done quite frequently).
* FreeRDP's server side does not have to set the supported encryption methods
list in settings->EncryptionMethods
Changes in this commit:
Removed unnecessary/confusing changes of EncryptionLevel/Methods settings
Refactor settings->DisableEncryption
* This value actually means "Advanced RDP Encryption (NLA/TLS) is NOT used"
* The old name caused lots of confusion among developers
* Renamed it to "UseRdpSecurityLayer" (the compare logic stays untouched)
Any client's setting of settings->EncryptionMethods were annihilated
* All clients "want" to set all supported methods
* Some clients forgot 56bit because 56bit was not supported at the time the
code was written
* settings->EncryptionMethods was overwritten anyways in nego_connect()
* Removed all client side settings of settings->EncryptionMethods
The default is "None" (0)
* Changed nego_connect() to advertise all supported methods if
settings->EncryptionMethods is 0 (None)
* Added a commandline option /encryption-methods:comma separated list of the
values "40", "56", "128", "FIPS". E.g. /encryption-methods:56,128
* Print warning if server chooses non-advertised method
Verify received level and method in client's gcc_read_server_security_data
* Only accept valid/known encryption methods
* Verify encryption level/method combinations according to MS-RDPBCGR 5.3.2
Server implementations can now set settings->EncryptionLevel
* The default for settings->EncryptionLevel is 0 (None)
* nego_send_negotiation_response() changes it to ClientCompatible in that case
* default to ClientCompatible if the server implementation set an invalid level
Fix server's gcc_write_server_security_data
* Verify server encryption level value set by server implementations
* Choose rdp encryption method based on level and supported client methods
* Moved FIPS to the lowest priority (only used if other methods are possible)
Updated sample server
* Support RDP Security (RdpKeyFile was not set)
* Added commented sample code for setting the security level
Also Use ANDROID_APP_TARGET_SDK for application compatibility project.
It is now automatically set/updated during build.
Note: The ANDROID_APP_TARGET_SDK version need to be larger or equal to the
version required by the used Android support library (appcompat).
"libfreerdp" consisted of multiple (small) single libraries. If the cmake
option MONOLITHIC was used only one library was build combining all of
the libfreerdp-* libraries.
The only exceptions to this are libfreerdp-server and libfreerdp-client these
are build as separate libraries.
This commit obsoltes non-monolithic builds and makes monolithic builds
the default. The cmake option MONOLITHIC is also removed.
