The versioning scheme used by Python (PEP 440) supports the rcN suffix
but development releases have to be named devN, not drN, which are
not supported and considered legacy versions.
This provides a fix if symmetrically overlapping policies are
installed as e.g. the case in the ikev2/ip-two-pools-db scenario:
carol 10.3.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
alice 10.4.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
Among others, the following FWD policies are installed on moon:
src 10.3.0.1/32 dst 10.4.0.0/16
...
tmpl ...
src 10.4.0.0/16 dst 10.3.0.1/32
...
src 10.4.0.1/32 dst 10.3.0.0/16
...
tmpl ...
src 10.3.0.0/16 dst 10.4.0.1/32
...
Because the network prefixes are the same for all of these they all have the
same priority. Due to that it depends on the install order which policy gets
used. For instance, a packet from 10.3.0.1 to 10.4.0.1 will match the
first as well as the last policy. However, when handling the inbound
packet we have to use the first one as the packet will otherwise be
dropped due to a template mismatch. And we can't install templates with
the "outbound" FWD policies as that would prevent using different
IPsec modes or e.g. IPComp on only one of multiple SAs.
Instead we install the "outbound" FWD policies with a lower priority
than the "inbound" FWD policies so the latter are preferred. But we use
a higher priority than default drop policies would use (in case they'd
be defined with the same subnets).
After adding the read callback the state is WATCHER_QUEUED and it is
switched to WATCHER_RUNNING only later by an asynchronous job. This means
that a thread that sent a Netlink message shortly after registration
might see the state as WATCHER_QUEUED. If it then tries to read the
response and the watcher thread is quicker to actually read the message
from the socket, it could block on recv() while still holding the lock.
And the asynchronous job that actually read the message and tries to queue
it will block while trying to acquire the lock, so we'd end up in a deadlock.
This is probably mostly a problem in the unit tests.
If there is currently no route to reach the other peer we just default
to left=%any. The local address is only really used to resolve
leftsubnet=%dynamic anyway (and perhaps for MIPv6 proxy transport mode).
Fixes#1375.
Metrics are basically defined to order routes with equal prefix, so ordering
routes by metric first makes not much sense as that could prefer totally
unspecific routes over very specific ones.
For instance, the previous code did break installation of routes for
passthrough policies with two routes like these in the main routing table:
default via 192.168.2.1 dev eth0 proto static
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.10 metric 1
Because the default route has no metric set (0) it was used, instead of the
more specific other one, to determine src and next hop when installing a route
for a passthrough policy for 192.168.2.0/24. Therefore, the installed route
in table 220 did then incorrectly redirect all local traffic to "next hop"
192.168.2.1.
The same issue occurred when determining the source address while
installing trap policies.
Fixes 6b57790270 ("kernel-netlink: Respect kernel routing priorities for IKE routes").
Fixes#1416.
An old (already rekeyed) CHILD_SA would get switched back into CHILD_REKEYING
state. And we actually want to change the currently installed CHILD_SA to
that state and later CHILD_REKEYED and properly call e.g. child_rekey() and
not do this again with an old CHILD_SA. Instead let's only check installed
or currently rekeying CHILD_SAs (in case of a rekey collision). It's also
uncommon that there is a CHILD_SA in state CHILD_REKEYED but none in state
CHILD_INSTALLED or CHILD_REKEYING, which could happen if e.g. a peer deleted
and recreated a CHILD_SA after a rekeying. But in that case we don't want
to treat the new CHILD_SA as rekeying (e.g. in regards to events on the bus).
When certificates are imported via Storage Access Framework we did handle
the selection directly in onActivityResult(). However, at that point the
activity might apparently not yet be resumed. So committing
FragmentTransactions could result in IllegalStateExceptions due to the
potential state loss. To avoid that we cache the returned URI and wait
until onPostResume() to make sure the activity's state is fully restored
before showing the confirmation dialog.
This fixes an interoperability issue with Windows Server 2012 R2 gateways.
They insist on using modp1024 for IKE, however, Microsoft's IKEv2
implementation seems only to consider the first 15 DH groups in the proposal.
Depending on the loaded plugins modp1024 is now at position 17 or even
later, causing the server to reject the proposal. By removing some of
the weaker and rarely used DH groups from the default proposal we make
sure modp1024 is among the first 15 DH groups. The removed groups may
still be used by configuring custom proposals.
onSaveInstanceState is apparently called after pausing the fragment and after
that committing any FragmentTransactions causes an IllegalStateException.
We could use commitAllowingStateLoss() but that's not really necessary
as we don't need to update when we are not active anyway. We also don't
update the view directly after registration as this happens
asynchronously, i.e. we might be paused when it finishes.
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).
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 adds a workaround for an issue on older platforms where the list is
not properly styled with colorAccent. Similarly applies to borderless buttons.
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.
Tobias Brunner