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.
This patch adds the autotools facilities to generate vapi files so that
libnm-util and libnm-glib can be consumed from Vala.
It depends on vapigen and it is a soft dependency.
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.
Unfortunately since libnm-glib/libnm-util make heavy use of
GHashTable and GValue, functions that deal with these types
can't be used from Python when using GObject Introspection,
since pygobject can't handle conversion between python types
and GValue/GHashTable very well. You'll likely encounter
assertions like:
ERROR:pygi-argument.c:1755:_pygi_argument_to_object: assertion failed: (g_type_info_get_tag (key_type_info) != GI_TYPE_TAG_VOID)
Aborted
Old plugins (ie, that aren't IPv6 capable) don't send the 'config'
signal, and thus have no way of signalling which IP methods they
have support for. Which means they won't set priv->has_ip4 and
thus the connect timer will kill the connection after a minute.
So track whether we got a 'config' signal, and if we didn't, but
we did get an 'ip4-config' signal (which means this is an old
plugin) then we just assume that the plugin supports IPv4. This
allows the connect timer to be canceled and the plugin to advance
to the STARTED state.
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.
