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.
This can happen e.g. when D-Bus limits number of replies and there's
a lot of connections. Then nm_remote_settings_list_connections() won't
return all connections and the connection that was activated can be among
the missing connections.
Commit 217c5bf6ac fixed processing of unix
signals: signals are blocked in all threads and a dedicated thread handles the
signals using sigwait().
However, the commit forgot that child processes inherit signal mask as well.
That is why we have to unblock signals for child processes we spawn from NM, so
that they can receive signals.
Instead of using the device's type number, which is a poor measure of
routing priority since it has nothing to do with routing priority,
let's make the decision more explicit.
The code to set up ATM interfaces is actually pretty simple,
so don't bother spawning br2684ctl at all. Just do the
necessary communication with the kernel directly and save
a bunch of code.
Note: this isn't very likely to work as I don't have an
ADSL connection to test with. Testing help appreciated.
This is the "juice" of the patch series. Initial cut at carrier handling
(by polling /sys/class/atm/$iface/carrier) and also support for calling
pppd with the proper command-line to achieve a connection.
Also implement the necessary boilerplate for the NM state machine to
be happy with our device.
This is a "duct tape and gum" implementation, i.e., prefer copy&paste
over proper refactoring, due to limited time, but the foundations are
now there, so we can make it work right slowly-slowly :)
With this patch, you can already test carrier management but not yet
make a complete connection.
Relevant extract from logs:
<info> (ueagle-atm0): carrier now ON (device state 20)
<info> (ueagle-atm0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
This patch adds the settings code (NMSettingAdsl) and the initial
"scaffolding" i.e., a tiny stub version of NMDeviceAdsl and the
udev handler code to get the device detected.
With this patch you should be able to see an atm device being detected
by networkmanager in the logs, although of course it doesn't
do anything useful yet.
Extract from the logs:
[1304668252.341354] [nm-udev-manager.c:562] adsl_add(): adsl_add: ATM Device detected from udev. Adding ..
(ueagle-atm0): failed to look up interface index
(ueagle-atm0): new ADSL device (driver: 'ueagle-atm' ifindex: -1)
(ueagle-atm0): exported as /org/freedesktop/NetworkManager/Devices/2
(ueagle-atm0): now managed
(ueagle-atm0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(ueagle-atm0): deactivating device (reason: 2).
[1304668252.345102] [nm-system.c:1349] flush_routes(): (ueagle-atm0) failed to lookup interface index
[1304668252.347821] [nm-device.c:3912] nm_device_state_changed(): (ueagle-atm0): device is available,
In this version, we hack the nm-device.c:nm_device_get_priority() to get better priority
instead of changing the DeviceType enum.
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
Finding out interface type from interface name string is fragile. It is easily
broken, e.g. by biosdevname changing interface names to em<n> or p<n>*p<n>.
Sadly, Gentoo network configuration scripts are rather stupid, using format:
variable_${interface|mac|essid|apmac}.
http://www.gentoo.org/doc/en/handbook/2007.0/handbook-x86.xml?full=1#book_part4_chap2
The entries interface|mac|essid|apmac are basically indistinguishable. It's not
possible to say whether 'p1p1' is an interface or SSID, for example.
Fix the current behaviour a bit by checking whether the string is an interface.
If so, and it is not a Wi-Fi one, set the connection type as wired. Else it is
regarded as wireless.
To simplify NMManager and to make use of the new connection provider
functionality, move the logic for when a paired Bluetooth device
is actually usable for network connections or not into the bluez
manager and out of NMManager. The general direction should be towards
moving this sort of logic out of the manager and into the device
specific stuff, like we did with the WiMAX bits, so we can make
stuff into plugins.
Kernel ifindexes are always greater than zero (see dev_new_index()
in net/core/dev.c). Also don't bother warning about ifindex
lookup failures for devices we know aren't kernel network interfaces.
GValueArray is deprecated as of GLib 2.32, but we need to use it for
dbus-glib stuff. So use the new GLIB_VERSION_MIN_REQUIRED macro to
prevent those warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=669613
The libertas driver now uses nl80211 for mesh, and wifi-utils chooses to
use wifi-utils-nl80211.
The wifi-utils-nl80211 code does not have implementations for
mesh_get_channel/mesh_set_channel and this breaks mesh networking.
Adding these methods under nl80211 is a little painful.
For now, force use of wifi-utils-wext to restore mesh networking.
The DHCP code usually ignores dhclient state transitions to the
same state it's currently in. This turns out to be wrong, since
dhclient will use the same reason code (which NM uses for the
state value) for operations like RENEW and REBIND. i.e. you'll
see states like this:
BOUND
RENEW (first renew)
RENEW (second renew)
RENEW (third renew)
etc
Therefore to ensure we trigger dispatcher scripts and internal
housekeeping code for renewals we need to make sure we process
these events even though they use the same state as the previous
event.
The DHCP code usually ignores dhclient state transitions to the
same state it's currently in. This turns out to be wrong, since
dhclient will use the same reason code (which NM uses for the
state value) for operations like RENEW and REBIND. i.e. you'll
see states like this:
BOUND
RENEW (first renew)
RENEW (second renew)
RENEW (third renew)
etc
Therefore to ensure we trigger dispatcher scripts and internal
housekeeping code for renewals we need to make sure we process
these events even though they use the same state as the previous
event.
The various nm_ip[46]_config_add_* routines were inconsistent in their
behavior when trying to add a duplicate item: add_address() and
add_route() would add it anyway; add_nameserver() and add_wins() would
g_return_if_fail(); and add_domain() and add_search() would return
silently. Update to use the "return silently" behavior everywhere.
In particular: if we get an RDNSS message listing the same nameserver
twice, don't cause a warning. (rh #820752)
