If the plugin says the user-provided secrets are insufficient,
make sure we fail instead of potentially overrunning the secrets
counter (which triggered an assert).
When the last character of the PSK was a backslash and the whole PSK was
enclosed in single quotes, the unquoting/unescaping code mistakenly took
trailing \' as an escaped quote and thus changed \ to '.
See also 79757f10f3 (that introduced the code).
This commit includes Dan Winship's implementation of IPv6
router solicitation. It also uses it as a last resort
for RDNSS and DNSSL lifetime expiry. While using RS to prevent
lifetime expiry may be deprecated and removed in the future,
the RS implementation is useful in other places too.
It can be also viewed as a last resort if commit e1cfdd5 gets
reverted/modified or if it does not work under some weird
circumstances.
It also includes improvements by cyphermox and me.
RFC 6106 says, section 5.1 says:
In order to provide fixed hosts
with stable DNS service and allow mobile hosts to
prefer local RDNSSes to remote RDNSSes, the value of
Lifetime SHOULD be bounded as
MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval
I have reported and repeatedly confirmed that values in this interval
trigger frequent RDNSS expiration on unreliable links such as 802.11
wifi. Wireless links *do* have packet loss and actually have a *much*
worse multicast packet loss than unicast. And regular router
advertisements are sent as multicast packets (in multicast frames).
In case of RDNSS expiration, NetworkManager tears down the whole
connection. That of course affects IPv4 networking as well as IPv6.
In a typical wireless network with radvd serving RDNSS it leads to
dropping network connection every ~10 minutes.
This commit improves the previous hack in 0b8ee13 by enforcing a minimum
lifetime of two hours (7200 seconds), which is four times the maximum
allowed value for MaxRtrAdvInterval (see below). We could use
AdvDefaultLifetime instead (as suggested by tore_ on IRC) but it doesn't
seem to be accessible through netlink.
RFC 4861 Neighbor Discovery for IP version 6 (IPv6):
MaxRtrAdvInterval
The maximum time allowed between sending
unsolicited multicast Router Advertisements from
the interface, in seconds. MUST be no less than 4
seconds and no greater than 1800 seconds.
This solution is not recommended by any RFC (and is in fact against
RFC 6106) but it's the easiest hack to fix the problem until IETF
takes action.
My original posting to IETF can be found here:
http://www.ietf.org/mail-archive/web/ipv6/current/msg15816.html
1fd11bd8d1 consolidated VPN connection
state handling, but that had the effect of making vpn_cleanup() be
called after all other handlers had processed the VPN connection
state change. This meant that the code in vpn_cleanup() that
reapplies the parent device's IP configs ran last, and that code
flushes routes on the device before reapplying them. Since the
policy is a listener on the VPN state change signals, it was
running the default routing updates before vpn_cleanup() got run,
resulting in vpn_cleanup()'s calls to nm_system_apply_ip4_config()
and nm_system_apply_ip6_config() blowing the default route away
which the policy had just set.
Fix that by moving the VPN routing cleanups into the policy, where
most of the routing decisions currently live, causing them to be
run before the default route is fixed up.
The patches that reduced the frequency of changes to /etc/resolv.conf
failed to prefer the VPN DNS information. Even though a VPN may not
be allowed to receive the default route, its DNS information still
needs to be higher priority than interface DNS info, otherwise no
sites on the VPN will be accessible due to glibc's in-order querying
of entries in /etc/resolv.conf.
Consolidate all the DNS handling in the policy instead of sprinkling
it around in the device and vpn code. This allows us to batch the
updates and thus reduce the number of times resolv.conf needs to
be written. It's also easier to follow when and why the changes
occur.
They won't always be updated together; if the hostname changes we
don't need to update routing, and if new routes show up we don't
need to update DNS. This also makes it a lot clearer what's
going on in the routing and DNS update functions.
There used to be two places state was handled: the function that was
called to change the state, and the object method handler for the
VPN connection class. Since the object method handler was marked
RUN_FIRST in it's g_signal_new() definition, we were destroying
internal class data (like the IPv4 config and IP iface) before other
listeners were able to deal with the state change.
That's all kinda pointless. Just consolidate the state change
handling and make all the cleanup for the DISCONNECTED/FAILED
states happen after other listeners have had a chance to process
the signal. It also makes the state change handling a lot clearer.
The previous code did a cheap hash based on pointers, under the
assumption that the IP configs don't get recreated. But with IPv6
the IP6 config that's eventually applied is a composite of the
DHCPv6 and the RA information, and is thus recreated each time
something in the DHCPv6 or RA changes. Switch to actually hashing
the IP config data and its order to prevent this problem.
Next, add functions to signal that a batch of updates will be
started, and to only commit those updates when all of them
have landed, and if they have actually changed anything. We'll
use these functions later to reduce the number of changes
that get made to /etc/resolv.conf.
Enabling NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_TEMP_ADDR in
nm_device_complete_connection() made IPv6 temp address enabled for connections
created via AddAndActivateConnection() D-Bus call. But it is disabled for other
connections. That is not much consistent. So, do not enable IPv6 privacy when
completing connections and leave it up to users, who would like to use IPv6
Privacy Extensions, to enable it manually.
The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO.
This works for most drivers but not all, e.g. for modems. We may figure out how
to get the info for specific devices, and enhance the solution by implementing
specific functions for particular device types later.
Usually if the BT link goes down we'll get some other signal of
failure, like PPP disconnect, or a Bluetooth disconnect. But if
the modem disappears from ModemManager for some reason while its
connected, make sure we clean up everything correctly.
The disconnect request gets sent just as a precaution, but usually when
the device fails the modem is already gone from ModemManager and the
Disconnect() method will fail. Just don't log the failure.
Allows devices to generically request authorization from the manager
for whatever operation they want, and allows us to keep the devices
from including the auth code directly.
DHCPv6 IA_NA assignments do not contain a prefix length, they are for a
single address (/128) only. However, the ISC DHCPv6 client incorrectly
assumes IA_NA assignments come with a implicit prefix length of /64, and
passes this incorrect information on to NetworkManager, which adds this
prefix as a on-link route. This will cause communication failures in
certain networks, for example NBMA networks, and in organisations using
longer prefix lengths than /64 for their LANs. For more discussion
regarding this problem, see RFC 5942 section 5.
This patch makes NM ignore the false prefix length attribute provided by
the ISC DHCPv6 client, instead setting it to a /128 (single address) in
all cases. Note that this does not preclude an on-link prefix from being
added by NM if it is being advertised in the correct way, i.e., by
including a Prefix Information Option with the L flag set in an ICMPv6
Router Advertisement.
For what it's worth I've also sent a patch to ISC to change the hard-
coded implicit prefix length value from /64 to /128 in [ISC-Bugs #29468].
The bug report describes a testing scenario where device is down
and no IPv4 or IPv6 addresses are set up. Then NetworkManager
is started and it decides not to configure DHCPv6 address. This
is caused by code copied from IPv4 that does not work here at
all (and I wonder if it does in IPv4).
In any case, when NetworkManager starts a DHCP client and recieves
an IPv6 address (no addresses are configured at the time), it
*must* send this new IPv6 address to the kernel.
(dcbw)
We should fix the connection takeover code for IPv6 but it's not
a quick fix so in the mean time disable the buggy code and we'll
fix IPv6 takeover cleanly soon.
Bug #676317 describes the following error:
NetworkManager[30151]: <error> [1337348764.559121] [nm-system.c:1121]
nm_system_replace_default_ip6_route(): (eth1): failed to set IPv6 default
route: -7
The above error is caused by NetworkManager assuming default gateways
belong to addresses but failing to setup default gateways for addresses
learned through DHCPv6.
This commit doesn't fix the fundamental issue but can be viewed as an ugly
workaround that gets IPv6 connection up and running. It doesn't fix
the fundamental flaw of binding gateways to IP addresses. They are
configured separately in IPv6 and NM should use lifetimes and allow
default gateway reconfiguration.
If the VPN plugin sends an empty IPv4 or IPv6 config, then treat it
like has-ip4/has-ip6 was FALSE. This way the plugin can just always
claim has-ip6 initially, and then send a blank config if it finds out
later that this particular connection doesn't do IPv6.
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
Even if a VPN is only tunneling IPv4, you might still be connected to
the tunnel endpoint via IPv6. Allow
NM_VPN_PLUGIN_IP4_CONFIG_EXT_GATEWAY to be either an IPv4 or an IPv6
address, and set up an appropriate static route either way.
libnl1 doesn't check the first argument and crashes on NULL.
I got NULL gateway out of rtnl_route_get_gateway() for link local and
multicast routes (fe80::/64, ff00::/8).
If there was an existing dhclient config file, don't leak it when
merging to the new configuration.
Found by Mathieu Trudel-Lapierre <mathieu@canonical.com>
There is are global caches of IPv6 addresses and routes. Only
managed devices are synchronized later. We *may* move
to per-device caches in the future but for now we should
keep the caches up to date.
Introduce logging of individual address and route changes. Rename
process_addr() and process_route() to process_address_change() and
process_route_change() so that it is clear that we react to both
addition and deletion.
Every state change should go through device_set_state(). This
static function provides state change logging. Function
state_to_string is moved up so that we can use it.
Split nm_ip6_device_sync_from_netlink into multiple functions.
It will now call the smaller functions and may disappear entirely
in the future.
To share state between these (and possible future) functions,
move local variables found_linklocal, found_other and dhcp_opts
to NMIP6Device as has_linklocal and has_nonlinklocal and dhcp_opts.
The kernel appears to always add a default route pointing to the router
that sent the RA, regardless of the contents of the RA:
ndisc_router_discovery() calls rt6_add_dflt_router() which calls
ip6_route_add() which calls __ip6_ins_rt() which calls fib6_add() which
calls fib6_add_rt2node(), which calls inet6_rt_notify(RTM_NEWROUTE, rt,
info)
So skip listening for RTM_NEWPREFIX and just rely on NEWROUTE instead.
The config_changed lost its meaning because RTM_NEWPREFIX was the only
case where it was FALSE.
It is bound to autoconnect_inhibit private variable (has opposite meaning).
While 'Autoconnect' is TRUE (default value) the device can automatically
activate a connection. If it is changed to FALSE, the device will not
auto-activate until 'Autoconnect' is TRUE again.
Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property
and schedules auto activation when FALSE->TRUE transition is made.
