If we mistakenly detect a new IKE_SA as a reauthentication the client
won't request the previous virtual IP, but since we already migrated
it we already triggered the assign_vips() hook, so we should reassign
the migrated virtual IP.
Fixes#1152.
Since the textual representation for a CRL is now standardized
in RFC 7468 one could argue that we should accept that too, even
though RFC 5280 explicitly demands CRLs fetched via HTTP/FTP to
be in DER format. But in particular for file URIs enforcing that
seems inconvenient.
Fixes#1203.
This replaces the EAP-Identity with the EAP-MSCHAPv2 username, which
ensures the client is known with an authenticated identity. Previously
a client with a valid username could use a different identity (e.g. the
name of a different user) in the EAP-Identity exchange. Since we use
the EAP-Identity for uniqueness checks etc. this could be problematic.
The EAP-MSCHAPv2 username is now explicitly logged if it is different
from the EAP-Identity (or IKE identity).
Fixes#1182.
This is particularly important for single valued rules (e.g.
identities). When copying values this is already handled correctly
by the enumerator and add().
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.
Since we don't use the kernel-netlink plugin anymore and the headers
in the NDK are reasonably recent, we don't need this anymore (at least
when building the app).
Fixes#1172.
We already did so during Phase 1 but because all three Quick Mode
message have the same message ID we occasionally dropped the third
message as retransmit, so we do it there too. For INFORMATIONAL
and TRANSACTION exchanges we don't expect more than one inbound message
with the same message ID so we still use them there.
Fixes#1198.
If the (un)registering of a kernel interface (net or ipsec) fails, the
plugin loader will never know, since the appropriate functions always
returns TRUE. By making the (un)register functions return a boolean
value, the loader can detect a failure during initializing the kernel
interface and abort charon startup if desired.
This ensures we don't pass data (via msg_control) defined in a different
scope to sendmsg(). Actually, some compilers (e.g. GCC 5.2.1) might
optimize the memcpy() call away causing the packets not to get sent from
the intended source address.
It also makes the code clearer than with all these ifdefs.
Fixes#1171.
