VLANs are only supported on certain kinds of devices, so don't try to
create them on other devices. (In fact, NM currently assumes that
VLANs are only created on Ethernet devices, so we need to be even more
picky than that.)
We go through the SECONDARIES state where we check if there are some secondary
(VPN or other) UUIDs that are to be activated before progressing to ACTIVATED.
In case of an error with a secondary UUID or its activation, the base connection
can't activate successfully.
When the supplicant starts connecting, or gets disconnected, track
whether it ever starts talking to an AP. Then if the connection fails
as a result of an initial connection timeout or a link timeout, we
can use SSID_NOT_FOUND when we're reasonably sure the AP doesn't
exist. Clients can use this to show better error messages.
Note that SSID_NOT_FOUND may only be reported when using nl80211
drivers, as WEXT drivers don't provide the status necessary to
determine whether the network exists or not.
Currently there's no way to differentiate between a connection that has
never been activated, and a connection that has never been *successfully*
activated. In both cases nm_settings_connection_get_timestamp() returns
zero. But it's useful to know whether a connection hasn't even been
tried yet, so enhance the timestamp code to return whether or not the
timestamp has been found in the timestamp cache or not, and make the
NMDevice core set an explict timestamp of 0 if the connection failed
on the first attempt.
We'll use this later to conditionally autoconnect WiFi connections
depending on whether they've ever successfully connected or not, but
still allow preloaded connections without a timestamp to autoconnect
as they always have.
Remove unused args for the non-VPN cases to cut down on the NULL NULL NULL
stuff since we're also adding two more arguments. Add the ability for
callers to give a callback that should be called when the dispatcher is
done.
Buggy kernel drivers sometimes default the carrier to ON when they
are capable of link-detection but the carrier is actually off, and
they quickly switch the carrier OFF when they determine actual
carrier state (cdc-ether, for example).
The initial carrier ON event would trigger a queued state change
from UNAVAILABLE to DISCONNECTED, which may auto-activate the
device. But before that state change happens, if a carrier OFF
event comes in, that queued state was not getting cleared and
the device would transition to DISCONNECTED even though the
carrier was off.
To ensure that never happens, and that we don't enter states that
aren't valid when the carrier is off, we need to clear any queued
state changes that wouldn't be valid in the new carrier state.
Implements a new property that provides a list of currently
available connections a device could connect to. For example
if a connection for a particular wireless connection exists and
that wireless network appears in the scan list it would show in the
AvailableConnections property of the device.
(dcbw: found a slightly cleaner way to do this; it's a lot like the
check_connection_compatible class method, except it deals with
live network data too. So convert the subclass methods to
just check additional live network data, and have the base
device class handle adding the connection to the hash and all
the associated signalling. Also fix a bug where the available
connections were not updated when a device moved from UNAVAILABLE
to available, its available connections were not updated)
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.
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.
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.
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.
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.
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.
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.
We need to set the interface's firewall zone before we kick off
any sort of IP configuration, so that rules for stuff like
DHCP are already handled by the time that these services are started.
Like IPv4, if the connection contains no IPv6 setting, perform
IPv6 addressing. Since may-fail defaults to TRUE for IPv6, failure
should have no consequence.
When we want to change the zone an interface belongs to
we can't use firewalld's addInterface() because this one
doesn't allow to add interface to zone when it already
has been part of some other/same zone.
We need to use changeZone() method instead - hopefuly
this is the final name of this method.
We already have the master device kept in the active connection, so
we can just use that instead of having the Policy determine and set
it manually. This also should allow slaves to auto-activate their
master connections if the master is able to activate.
This function used to be used only from activation paths, so it
was fine to assert there because we always expected that there
would be an activation request. These days we'd like to use it
in more places, so just return NULL if there's no connection.
We'll want to eventually match (for VLAN) a given hardware address
that's not the device's hardware address. Only the device itself
knows which NMSetting should contain it's hardware address (ie
the 'wired' setting for NMDeviceEthernet, 'infiniband' for
NMDeviceInfiniband, etc) and VLANs take their hardware address
from the parent interface. So eventually we'll have VLAN
interfaces use these new arguments to ask their parent interface
to match the VLAN hardware address in a connection, since the
VLAN doesn't know (or need to know) what kind of interface it
really is underneath.
- changes nm_utils_get_proc_sys_net_value() to allow all values, not just 0,1
- adds nm_utils_get_proc_sys_net_value_with_bounds() for limiting valid values
To suppress periodic disk wakeups, only write timestamps to disk
when a device gets activated or deactivated. Timestamps are
still updated periodically in memory, just not flushed to disk
at that time.
