Since comments in resolv.conf are only valid at the beginning of a line
resolvconf(8) seems to have started treating any text after
'nameserver <ip>' as additional IP addresses for name servers.
Since it ignores comments, and we can easily remove the added servers
again, there is no point to add any.
Fixes#410.
The flag is required to convince libtool on Cygwin to build DLLs. But on
Windows these shared libraries can not have undefined symbols, so we have to
link them explicitly to the libraries they reference.
For plugins this is currently not done, so only the monolithic build is
supported. The plugin loader wouldn't be able to load DLLs anyway, as
it tries to load files that don't exist on Cygwin.
Commit 940e1b0f66 "Filter ignored
interfaces in kernel interfaces (for events, address enumeration,
etc.)" made charon to ignore routes with unusable interfaces.
Unusable interface is one where charon has not seen RTM_NEWLINK
message from the kernel.
Sometime RTM_NEWLINK message can be 1048 bytes large. This is
24 bytes more than currently allocated buffer of 1024 bytes.
If kernel sends such a large message, then it would be silently
ignored by charon and corresponding interface would never become
usable. Hence strongSwan might resolve invalid source IP address
in get_route() function. This would prevent IPsec tunnel to be
established.
To reproduce create a VLAN interface with following command:
vconfig add eth1 12
The retry code introduced in dc8b083 got the memset() arguments wrong.
Fix this to ensure the buffer gets zeroed, for real.
It probably doesn't matter as we do reset the message length on retry, so
the stale data shouldn't be seen by anyone.
Found-by: git grep 'memset\s*\([^,]*,\s*[^,]*,\s*0\s*\)'
Since f52cf07532 addresses on ignored, down or loopback interfaces were
not considered as valid addresses anymore when searching for an address
contained in the local traffic selector. This meant that route
installation failed, for instance, if charon.install_virtual_ip_on was
set to 'lo', or, on gateways, if internal interfaces were ignored with
the charon.interfaces_* options.
If multiple roam events are triggered within ROAM_DELAY, only one job is
created. The old code set the address flag to the value of the last
triggering call. So if a route change followed an address change within
ROAM_DELAY the address change was missed by the upper layers, e.g. causing
it not to update the list of addresses via MOBIKE.
The new code now keeps the state of the address flag until the job is
actually executed, which still has some issues. For instance, if an
address disappears and reappears within ROAM_RELAY, the flag would not
have to be set to TRUE. So address updates might occasionally get
triggered where none would actually be required.
Fixes#374.
Mainly for reauthentication with third party implementations, we allowed to
reuse an online lease, but only for the same peer identity and when it
explicitly requested the same address.
This has always been problematic, because it changes the reqid of the CHILD_SA
with the same traffic selectors, breaking the old tunnel. As we now reject
such policy overwrites, this usually lets the installation of the new policies
fail. We therefore disable reassignment of online leases by default.
When we reassign an online lease for the same peer, we have to refcount it.
Otherwise we would set it offline if one of the tunnels goes down, but it is
actually still in use by a the second tunnel. This can finally lead in
assigning the same virtual IP to different peers.
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
It seems we sometimes get the virtual IP as source (with
rightsubnet=0.0.0.0/0) even if the exclude route is already
installed. Might be a timing issue because shortly afterwards the
lookup seems to succeed.
If IPsec SAs are rekeyed due to an address change (e.g. because
update_sa is not supported) the exact same policy with the same reqid
will be installed, but with different addresses. After the rekeying the
old SA and its policies are removed, using the first matching mapping
breaks the mapping between the policies and the new SA (at least on
FreeBSD, the Linux kernel might only use the reqid for this). Using the
oldest matching SA is still an approximation but it solves the above
issue.
This was noticed on Mac OS X where, if the default route is returned,
RTA_NETMASK has sa_len set to 0, but skipping zero bytes to read the
next address makes no sense, of course. Using 0 for sa_len seems
a bit strange, in particular, because struct sockaddr has by definition
a minimum length of 16 bytes. But it seems FreeBSD actually does the
same.
Tobias Brunner