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.
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.
