Before platform raised 3 signals for each object type. Combine
them into one and add a new parameter @change_type to distinguish
between the change type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until
both IPv4 and IPv6 are ready. This especially has an effect on
nm-online/NetworkManager-wait-online.service, which blocks until
configuration of both IPv4 and IPv6 is ready.
We queue a pending_action when automatic configuration starts and
remove it again, when we receive an address. Before, "startup complete"
was reached when either one of the two IP protocols was configured.
https://bugzilla.redhat.com/show_bug.cgi?id=1086906
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a parameter to nm_device_add_pending_action() to silently
accept adding duplicate actions.
Same for nm_device_remove_pending_action(), to silently ignore
removing non-pending actions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At a later point, we will have to make a copy of @dhcp_anycast_addr to start
the client asynchronously. Although the length of the guint8 array *should*
always be 6 byte (being a MAC address), it's nicer to just pass on the
GByteArray instance instead, which knows how many byte are actually
set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Clients such as gnome-control-center or nm-applet show
at some places only one (IPv6) address. They most likely
just pick the first address from the list of addresses,
so we should order them.
Sorting has the advantage to make the order deterministic --
contrary to before where the order depended on run time conditions.
Note, that it might be desirable to show the address that the kernel
will use as source address for new connections. However, this depends
on routing and cannot be easily determined in general. Still, the
ordering tries to account for this and sorts the addresses accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=726525
Signed-off-by: Thomas Haller <thaller@redhat.com>
Instead of tracking unmanaged-ness in a couple variables (and because
I'd like to add one for user-unmanaged later) let's do it in a single
flags variable, and consolidate setting of the unmanaged states in one
place.
Even ignore-carrier devices need to be aware of carrier-up events so
they can continue DHCP when the link comes up. They just ignore all
carrier-down events.
After applying a configuration with static IPv4 addresses, call
/sbin/arping to announce the new addresses to the host's neighbors.
(Basic idea copied from Fedora ifup-eth.)
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="23466771-f5fa-4ca9-856f-eaf4a8e20c3f"
BOOTPROTO=none
IPADDR="10.0.0.2"
PREFIX="24"
GATEWAY="10.0.0.1"
HWADDR="52:54:00:12:34:56"
TYPE=Ethernet
NAME="ens3"
This ifcfg file results in connection.interface-name=ens3.
However, device-generated connection didn't set interface-name property.
Fix that by setting interface-name property when generating a connection. Also
allow matching connections if interface-name is not set in a connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1077743
The AC doesn't get a D-Bus path until it's exported, but that happens after
it's handed to the Device it will be activated on. The Device emits a
PropertyChanged event when it's handed the AC, but it ignores ACs that
aren't exported yet. Thus when activating, the Device doesn't emit the
AC's path at all in the ActiveConnection property because it's NULL.
Fix that by exporting the AC immediately before starting activation
with it.
Second, move the notification of the Device.ActiveConnection property
to be emitted along with the state change to PREPARE instead of long
before it. While we don't guarantee signal ordering in general, this
seems like a more correct ordering.
https://bugzilla.gnome.org/show_bug.cgi?id=723783
nm_device_deactivate() is used when deactivating a device, but also
when initializing it when it is first managed. Rename it to
nm_device_cleanup(), and use a different log message ("preparing
device") in the NM_DEVICE_STATE_REASON_NOW_MANAGED case.
If a device had its carrier ignored, and did not have a carrier on startup,
then NetworkManager would not re-check autoconnect connections when the
device's carrier appeared. Because ignore-carrier devices are always
in DISCONNECTED state when they are managed, the nm-device.c::carrier_changed()
code essentially did nothing when the carrier appeared. It needs to
also trigger an auto-activation recheck signal when the carrier appears
to ensure that now-valid connections (like those that require DHCP or
IPv6) can be auto-activated.
Devices disconnected explicitly by user should stay disconnected, preventing
auto-connecting until manual request.
Introduction of NM_DEVICE_STATE_DEACTIVATING state broke this feature.
disconnect_cb() correctly set autoconnect device property to FALSE, however
nm_device_state_changed() put it to TRUE again. Thus only the active connection
was blocked instead of the whole device.
https://bugzilla.gnome.org/show_bug.cgi?id=726239
Because not all clients set the 'hidden' property in a connection for
hidden/non-SSID-broadcasting networks, they may not show up in
the device's available-connections property. After the
PendingActivation object removal, all activations require the
connection to be in available-connections, and thus hidden SSID
networks could not be activated.
Unfortunately check_connection_available() is used both during
activation and to populate the available-connections array, but we
only want to special-case activation paths, and still ensure that
SSIDs not found in the scan list are not in available-connections.
To make it clear this is a WiFi only hack, and that we should
remove it at some point in the future, create another class method
specifically for hidden WiFi and use that in activation paths to
special-case hidden WiFi connection activation.
Instead of only passing the ifindex to the callback, pack
additional data. This allows for better logging by also
writing the g_idle_add id which allows to associate the scheduling
with cancel calls.
Also, this fixes that the callback could not clear the
@delete_on_deactivate_id of the device, so that a following
delete_on_deactivate_unschedule() would think that there is
still something to cancel.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes queued activation request to be aborted because the software
device gets removed before the device reaches the PREPARED state.
This happens, because when the previous connection disconnects, the
device will schedule its removal.
https://bugzilla.redhat.com/show_bug.cgi?id=1073015
Signed-off-by: Thomas Haller <thaller@redhat.com>
Setting the address flag IFA_F_NOPREFIXROUTE broke adding the device route to
the IPv6 prefix because the check for nm_ip6_config_destination_is_direct()
caused the route to be skipped. This, together with the kernel no
longer adding the prefix route resulted in no device route for autoconf
/64 prefixes.
https://bugzilla.redhat.com/show_bug.cgi?id=1068632https://bugzilla.redhat.com/show_bug.cgi?id=1072410
Signed-off-by: Thomas Haller <thaller@redhat.com>
The IPv6 spec say that when performing SLAAC, you should sent at most
3 RSes, at least 4 seconds apart. We were previously continuing to
send RSes forever if we didn't get back a response. Fix that.
(Since the fix involves making nm-lndp-rdisc use NMPlatform, it was
necessary to rewrite the rdisc test program a bit, to not try to
include <net/if.h>, which is incompatible with <linux/if.h>.)
This got broken at some point. The intent of ignore-carrier was always
to ignore the carrier for IP configuration for static/manual connections,
but never for DHCP/SLAAC where a link is actually required. Thus
when checking whether to postpone IP configuration for a master interface
that's using DHCP/SLAAC, don't allow ignore-carrier to factor into
the decision.
Add a generic signal that devices can use to indicate that something
material in the network situation changed, and that auto-activation
may now be possible. This reduces specific knowledge of device types
in the policy.
In preparation for making WWAN and Bluetooth plugins, rework
the device plugin interface to meet those plugins' needs and
port WiMAX over in the process.
In reality the connection provider (NMSettings) is always the same
object, and some device plugins need access to it. Instead of
cluttering up the device plugin API by passing the provider into
every plugin regardless of whether the plugin needs it, create
a getter function.
We don't want the kernel to do IPv6 addrconf, but we do want it to
notice the non-router-related fields in the RA (eg, Retrans Timer) and
update the interface state to reflect them. So instead of turning off
accept_ra, we leave it turned on, and turn off accept_ra_defrtr,
accept_ra_rtr_pref, and accept_ra_pinfo instead.
If a device is already activated, queue the new activation to allow
the transition through the DEACTIVATING state.
---
Also remove the "HACK" bits in nm_device_deactivate(). This hack was
added on 2007-09-25 in commit 9c2848d. At the time, with user settings
services, if a client created a connection and requested that NM
activate it, NM may not have read the connection from the client over
D-Bus yet. So NM created a "deferred" activation request which waited
until the connection was read from the client, and then began activation.
The Policy watched for device state changes and other events (like
it does now) and activated a new device if the old one was no longer
valid. It specifically checked for deferred activations and then
did nothing. However, when the client's connection was read, then
nm-device.c cleared the deferred activation bit, leading to a short
period of time where the device was in DISCONNECTED state but there
was no deferred activation, because the device only changes state to
PREPARE from the idle handler for stage1. If other events happened
during this time, the policy would tear down the device that was
about to be activated. This early state transition to PREPARE
worked around that.
We need to remove it now though, because (a) the reason for its
existence is no longer valid, and (b) _device_activate() may now
be called from inside nm_device_state_changed() and thus it cannot
change to a new state inside the function.
Actually, get_ip_ifindex() should always return 0 or > 0. Just in case,
be extra careful and modify the conditions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a regression introduced in 5074898591.
The while loop did only refetch the cached value (because the glib main loop
was blocked and only the cached device flags were checked).
Also, instead on relying of g_usleep(), wait until a maximum time of waiting
is expired. The duration of g_usleep() might not be very accurate.
Also, do no longer check the cached device state before setting the
device flag. The cache might be out of date, so we just set the flag.
https://bugzilla.gnome.org/show_bug.cgi?id=724363
Signed-off-by: Thomas Haller <thaller@redhat.com>
This feature needs support from the kernel and libnl.
If there is no system support, NM acts as before, adding the
autoconf address as /128. It does so, to prevent the kernel
from adding a route for this prefix. With system support, we
add the address as /64 and set the flag IFA_F_NOPREFIXROUTE.
https://bugzilla.redhat.com/show_bug.cgi?id=1044590https://bugzilla.redhat.com/show_bug.cgi?id=1045118
Signed-off-by: Thomas Haller <thaller@redhat.com>
NetworkManager uses the sysctl value 'max_addresses' as the kernel does.
There is however a difference in what addresses are taken into account.
The kernel counts all addresses on the interface (including temporary,
private addresses and user configured ones).
NM instead only limits the number of public autoconf addresses to
'max_addresses'. This is because it is difficult for NM to count all
addresses (which can come from different sources) and it is not
necessarily a more logical behavior. Only be aware, that NM uses
the same config value as the kernel, but counts differently.
Especially, the kernel might reach the limit earlier then NM in the
presence of temporary addresses or addresses not from SLAAC.
Note, that the kernel uses 'max_addresses' only to limit public, autoconf
addresses. So this limit does not affect NM adding as many addresses as
it wants.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
