When adding Routes to zerotier's Managed Routes, the helper will
add a route rule to the device that does not have a via ip,
so that the address of the Destination segment cannot be routed
correctly within the container.
Here, based on the contents of the routes key in
`zerotier-cli -j listnetworks`,
by determining whether the via key has an ip address,
if it is not null, helper will no longer add route rules.
ARM Cryptography Extension is optional and not all ARM CPUs support it.
For example, the CPU in Raspberry Pi 4 does not support it.
Check for `__ARM_FEATURE_CRYPTO` before attempting to use the optional
extension.
`__ARM_FEATURE_CRYPTO` is defined by both clang and gcc when the target
has the cryptography extension.
Fixes#1854.
Client side:
* Fix compatibility with OneLogin
* Requested scopes vary by OIDC provider. Different providers have different
Controller side:
*Update Postgres queries to latest Central schema
* Added Central Controller support for the different providers
* Base OIDC provider details are still attached to an org. Client ID & group/email lists are now associated with individual networks.
Xcode warns about "Possible misuse of comma operator here".
Comma is a sequencing operator in C++ and original code does work, but
is highly non-idiomatic.
This patch implements a "TUNNELED" status indicator and "forceTcpRelay" setting for custom relays via local.conf.
For example:
{
"settings":
{
"tcpFallbackRelay": "6.79.53.215/443",
"forceTcpRelay":true
}
}
If you have a VM host like parallels, sometimes you get these link-local
default routes:
```
netstat -nrfinet | grep "default\|\/1"
0/1 10.2.0.12 UGScg feth4823
default 192.168.82.1 UGScg en1
0/1 192.168.82.1 UGScIg en1
default link#22 UCSIg bridge101 !
128.0/1 10.2.0.12 UGSc feth4823
128.0/1 192.168.82.1 UGScI en1
```
(the link#22 one)
The _getRTEs function inclused these routes in the list it makes as like:
device: bridge101, target: 0.0.0.0/0
If it happens to be first in the list, bridge101 gets
selected as the default route.
Then Full Tunnel Mode doesn't work.
The other routes in the list are like:
device: en1 target: 192.168.1.0/24 via: metric: 0 ifscope: 0
device: en1 target: 192.168.1.1/32 via: metric: 0 ifscope: 0
We only need the device name from this, so either one will work.
Through using ndk-build, -Wno-unused-command-line-argument is passed in
somewhere in the pipeline and hides this warning.
The warning can be turned on with:
APP_CPPFLAGS := -Wunused-command-line-argument ...
and then when building, you can see:
C/C++: clang++: warning: argument unused during compilation: '-mfloat-abi=softfp' [-Wunused-command-line-argument]
C/C++: clang++: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
C/C++: clang++: warning: argument unused during compilation: '-maes' [-Wunused-command-line-argument]
These are unused because both floating-point and NEON are required in
all standard ARMv8 implementations. [1] [2]
[1] https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
[2] https://stackoverflow.com/a/29891469
Since NDKr15 (released 2017), unified headers are used by default [1]
Remove -isystem option that was passing bad values to command-line.
The actual value being passed to command-line was:
```
-isystem DK/sysroot/usr/include/RIPLE
```
because of using $NDK and $TRIPLE instead of $(NDK) and $(TRIPLE)
But regardless, $NDK and $TRIPLE were never actually defined values and were just
place-holders mentioned in [1]
[1] https://android.googlesource.com/platform/ndk/+/ndk-release-r16/docs/UnifiedHeaders.md
