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.
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.
Currently the .gir files for NetworkManager-1.0 and NMClient-1.0 declare
their dependencies twice, once with the GIR name and another one with
the pkg-config name. This causes problems with Vala bindings generation.
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.
