| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Because the support library creates its own layout manually and uses
different IDs than the list_content layout we can't use the method we
used previously (and which is actually recommended in the docs).
|
|
|
|
|
|
|
|
|
| |
warnings
For instance, onAttach() with an Activitiy as first argument was deprecated
with API level 23. However, the overload with a Context as first argument
does obviously not get called on older API levels. Luckily, the classes
provided by the support library handle that for us.
|
| |
|
|
|
|
|
| |
This avoids issues with recursion, which could have happened if the
strongswan directory was a symlink.
|
| |
|
|
|
|
|
| |
This adds a workaround for an issue on older platforms where the list is
not properly styled with colorAccent. Similarly applies to borderless buttons.
|
|
|
|
|
| |
When using the application context theme customizations wouldn't get
applied for some reason.
|
|
|
|
|
|
| |
The term "gateway" is unfamiliar for most new users (or they confuse it
with the default gateway of their network) but they usually know that
they want to connect to a "server".
|
|
|
|
|
|
|
| |
This mainly changes the color of the appbar (colorPrimary), the color
of the status bar (colorPrimaryDark) is black like the default.
The accent color (colorAccent) used for controls like buttons and check
boxes is a slightly toned down version of the default.
|
| |
|
| |
|
| |
|
|
|
|
| |
Instead we use TabLayout and ViewPager from the support libraries.
|
|
|
|
| |
No need to manually reset the fragments anymore.
|
|
|
|
|
| |
Observers are notified when the manager is reset (and initially when the
certificates are first loaded).
|
|
|
|
|
|
|
| |
There is no AppCompatProgressDialog class as the use of ProgressDialog
is discouraged (instead progress bars should be placed in the layout directly).
To display the current ProgressDialog instances correctly on systems < 21 we
modify the window background color.
|
|
|
|
|
| |
Also includes some whitespace/formatting changes due to the switch to
Android Studio.
|
| |
|
|
|
|
|
|
|
| |
We'll have to change some stuff that Google deprecated (e.g. the tabs in
the ActionBar) and that requires changing the theme at least in activities.
Since that would look a bit inconsistent we'll change it globally and
use parts of the support library.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
While building against this level in general would break our app on
older systems, the NDK will automatically use this level for 64-bit
ABI builds (which are not supported in older levels). So to build
against 64-bit ABIs we have to support this API level.
|
| |
|
|
|
|
| |
This moves hydra->kernel_interface to charon->kernel.
|
|
|
|
|
|
| |
We already do this for the other kernel interfaces.
Fixes e1e88d5adde0 ("libipsec: Don't attempt deletion of any non-IPsec policies")
|
|
|
|
|
|
| |
in the set
Fixes #1213.
|
|
|
|
|
| |
Triggered by -Wextra for many INIT usages where we only partially
initialize a struct.
|
| |
|
|
|
|
|
|
|
|
| |
In Java all integer types are signed, when a negative integer is casted
to a larger type (e.g. int to long) then due to sign extension the upper
bytes are not 0. So writing that value to a byte array does not produce
the expected result. By overloading the putX() methods we make sure to
upcast the values correctly.
|
|
|
|
|
| |
This uses a manual way to trigger the NDK build (the default with
on-the-fly Android.mk files does not work for us).
|
|
|
|
|
|
|
| |
add_policy()
The additional data can be helpful to identify the exact policy to
delete.
|
|
|
|
|
|
|
| |
This is basically the same call, but it has the advantage of being
supported by FreeBSD's valgrind, which sigwait() is not.
References #1106.
|
| |
|
| |
|
|
|
|
|
|
| |
The headers/libraries changed a lot with level 21 so that our app won't
run on devices with Android < 5 when built against it. We currently
don't need any new native APIs so that should be fine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android blocks traffic for address families for which no IPs, DNS servers
or routes are installed via VpnService.Builder. Since Android 5+ (API
level 21) it is possible to explicitly allow such traffic to bypass the VPN.
So for proper split tunneling we note whether we saw a VIP and/or DNS
server of a specific family, and if not, allow traffic of that family
to bypass the VPN using the new API (on older systems there is no change
and such traffic will still be blocked). Otherwise, we do what we did so
far, that is, simply install the received routes (traffic selectors), all
other traffic will not be directed to the TUN device and use the underlying
network instead.
If traffic for a family should be blocked we install a default route via
TUN device even if we received more specific traffic selectors from the
server. libipsec will use the actual traffic selectors as IPsec policies
and drop any packets it received that don't match them. We only do this
if we saw any VIPs or DNS servers of a family. Otherwise the traffic for
that family is blocked anyway.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address found
In dual-stack environments the IPv6 connectivity (via autoconfiguration)
might be established before the IPv4 connectivity (via DHCP). It seems
Android triggers the CONNECTIVITY_ACTION broadcast already when the first
family is fully configured. At that time we might not be able to find an
IPv4 source address. And since Android does not trigger the broadcast
again if IPv4 connectivity is established, the connection is broken
afterwards.
So we store the connectivity state and if we are reportedly connected but
still find no source address we trigger a roam event to recheck for an IPv4
address. This will cause regular rechecks if a device enters an IPv6-only
network, but I guess that's rare (otherwise we could limit the number of
rechecks done between connectivity changes).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before fwmarks were used protected sockets were bound to the outbound
interface via SO_BINDTODEVICE. This does not always seem to work well
together with our connect()/getsockname() trick if the server is covered
by the traffic selectors. Calling protect() again after disconnecting
the socket seems to help, but if there is no connectivity at all we still
get the virtual IP back (maybe protect() does not bind the socket to any
interface then).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When roaming from a mobile network to WiFi on Android 5.x the event
received via ConnectivityManager is triggered before the mobile
connection is fully torn down (i.e. before the interface is disabled and
the routes disappear). So for strongSwan the current path still seems
valid and since no roam event is triggered later the daemon never switches
to WiFi and the connection is broken afterwards.
A possible solution to this is enabling roam events in the kernel-netlink
plugin. That would trigger an event when the device is finally disconnected
from the mobile network. However, this could actually take a some time,
during which traffic continues to be sent via mobile network instead of WiFi.
That's because Android now uses multiple routing tables, routing rules and
fwmarks to direct traffic to the appropriate interface/table, but in our
plugin we don't have the information available that would allow us to make
the switch to a different network/routing table earlier (and we actually
prefer the current path if it is still valid). Additionally, the plugin
produces quite a bit more events than ConnectivityManager (which was one
of the reasons to use the latter in the first place).
This custom kernel-net implementation is now specifically tailored for
Android. Roam events are still triggered via ConnectivityManager but
the source address is determined via connect()/getsockname() on a VPN
excluded UDP socket, which does use the correct routing table as intended
by Android. That way the daemon immediately sees a different source IP
when connectivity changes even if the device is connected to multiple
networks concurrently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an issue when using the Android M preview. Bionic's dynamic
linker was changed so that symbols in libraries loaded with RTLD_LOCAL
were not found anymore in dlsym(RTLD_DEFAULT, ...). This is the case
for libraries loaded with System.loadLibrary(), therefore, the plugin
loader in libstrongswan was not able to resolve any symbols defined in
other libraries loaded later. While this seems to have been broken
unintentionally for existing apps (fix at [1]), it will again be a
problem whenever we decide to increase targetSdkVersion beyond 22 (or
until that fix makes it into the system/emulator images).
Unfortunately, the dynamic loader in releases prior to Android 4.3 can't
load libandroidbridge without also loading its dependencies.
[1] https://github.com/android/platform_bionic/commit/1913352c6b
|
| |
|