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
Surface Addresses are the addresses that
the roots report back to you.
This is helpful for trouble shooting.
If you're behind NAT, the source port is different
than what zerotier is bound to.
If the list of surface address ports is larger than the list of
bound addresses, you are probably behind symmetric NAT.
Anways this can be added to later with a more simple
"easy" or "hard" nat computed message somewhere.
