Instead of creating most routes with metric 0 and then fixing them
just before applying them, create the routes with the correct metric
in the first place (so that NMIP4Config and NMIP6Config don't have to
try to guess whether "metric 0" means "unset" or "actually metric 0").
If a link's "master" property changes unexpectedly (ie, from outside
NM), update the master and slave NMDevices to reflect it, without
making any changes to them.
The process of activating a slave requires that its master have an
NMActiveConnection. So don't allow generating a connection on a slave
until we have generated the connection on the master.
nm_device_generate_connection() was allowing connections for master
devices to have no IP config, but this didn't really make much sense,
since they would just fail at stage3 in that case anyway.
Now that we get multiple tries at generating a connection on a device,
we can just ignore the device until it has a proper connection.
If the initial attempt to assume a connection on a device fails, and
the device remains un-activated, but then something changes its
configuration externally, try to generate a new connection and assume
that.
If the IP config changes on a device that has assumed a generated
connection, then update the connection's NMSettingIP4Config /
NMSettingIP6Config, under the assumption that the configuration of
that device was in progress but incomplete when NM first observed it.
NMIP4Config and NMIP6Config had methods to update an existing
NMSetting. However, the functions would really only work correctly if
the passed-in setting was empty.
Change them from "update_setting" to "create_setting", and have them
create the NMSetting themselves, and update NMDevice for that.
(If we need update_setting later, we can add it, after figuring out
exactly how it's actually supposed to work.)
Firewalld call addInterface() fails with ZONE_CONFLICT if the interface
is already part of another zone. This complicates the code in NM,
because we would have to keep better track of the zone in which the
interface currently is. Which might be quite difficult because
the zone might be changed from an external program (so we would have
to monitor the firewall configuration and work around potential races).
A better and simpler fix is to simply always use the changeZone() call.
This will do the right thing, regardless if the interface is already part
of a zone or not.
https://bugzilla.redhat.com/show_bug.cgi?id=1103782
Signed-off-by: Thomas Haller <thaller@redhat.com>
The firewalld removeInterface call fails with ZONE_CONFLICT when
removing an interface from a wrong zone. This can happen, when the
connection gets modified, while being active (which is related to
bgo#724041).
By not specifying any zone, we remove the interface from the zone
where it currently is added. This behavior was introduced in upstream
firewalld with commit cc3101ab70a3997228be7bc9f45a069c7fccfa36, March 2012,
r0_2_3-1.
This is the behavior we actually want and we don't have to keep proper track
of the current zone.
https://bugzilla.redhat.com/show_bug.cgi?id=1103782
Signed-off-by: Thomas Haller <thaller@redhat.com>
Fixes the following g_warn():
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003370c50956 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000439962 in carrier_changed (device=0x1d94300, carrier=1) at devices/nm-device.c:1021
#4 0x0000000000488f12 in carrier_changed (device=0x1d94300, carrier=1) at devices/nm-device-ethernet.c:1646
#5 0x0000000000434c94 in nm_device_set_carrier (device=device@entry=0x1d94300, carrier=1) at devices/nm-device.c:1104
#6 0x0000000000434dd5 in check_carrier (device=device@entry=0x1d94300) at devices/nm-device.c:1298
#7 0x0000000000434ef8 in constructed (object=0x1d94300) at devices/nm-device.c:550
#8 0x0000003371c15d87 in g_object_new_internal () from /lib64/libgobject-2.0.so.0
#9 0x0000003371c17814 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#10 0x0000003371c17c11 in g_object_new () from /lib64/libgobject-2.0.so.0
#11 0x000000000048bc2e in nm_device_ethernet_new (platform_device=platform_device@entry=0x1d82e58) at devices/nm-device-ethernet.c:336
#12 0x000000000047c600 in platform_link_added (self=0x1d70150, ifindex=ifindex@entry=2, plink=plink@entry=0x1d82e58, reason=reason@entry=NM_PLATFORM_REASON_INTERNAL) at nm-manager.c:1954
#13 0x000000000047c7db in platform_link_cb (platform=<optimized out>, ifindex=2, plink=0x1d82e58, change_type=<optimized out>, reason=NM_PLATFORM_REASON_INTERNAL, user_data=0x1d70150) at nm-manager.c:2038
#14 0x0000003371805d8c in ffi_call_unix64 () from /lib64/libffi.so.6
#15 0x00000033718056bc in ffi_call () from /lib64/libffi.so.6
#16 0x0000003371c10ad8 in g_cclosure_marshal_generic () from /lib64/libgobject-2.0.so.0
#17 0x0000003371c10298 in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#18 0x0000003371c2235d in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0
#19 0x0000003371c2a0f2 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#20 0x0000003371c2a3af in g_signal_emit () from /lib64/libgobject-2.0.so.0
#21 0x000000000044f6ba in nm_platform_query_devices () at platform/nm-platform.c:330
#22 0x000000000047de4c in nm_manager_start (self=0x1d70150) at nm-manager.c:4025
#23 0x0000000000429d31 in main (argc=1, argv=0x7fffb4c31628) at main.c:654
https://mail.gnome.org/archives/networkmanager-list/2014-June/msg00000.html
Signed-off-by: Thomas Haller <thaller@redhat.com>
Thomas points out that the previous refactoring moved the
link_changed() virtual method invocation relative to
update_for_ip_ifname_change(), which could have weird side effects
given the things that can happen there. So move it back.
Bond, bridge, and team were notifying their "slaves" properties before
the slave actually got removed from priv->slaves, meaning that
anything that looked at the property directly from a notify::slaves
handler would see the old value. Fix that.
Keep priv->slaves in the order that slaves were attached, rather than
in reverse order.
Among other things, this makes the errors from
nm_device_master_check_slave_physical_port() more consistent.
If IPv6 completes first it would emit the "up" dispatcher event with IPv6
details and move the device to ACTIVATED state. But if DHCPv4 was still
running, no dispatcher event would be emitted with the DHCPv4 information
until the first lease renew. Thus dispatcher scripts would not receive
DHCPv4 information for quite some time.
Ensure that if the other IP version completes first, that when the slower
method's DHCP completes, that it emits the appropriate dhcp4-change
or dhcp6-change event so that dispatcher scripts get the information
as soon as it's available.
https://bugzilla.gnome.org/show_bug.cgi?id=729284
If the given PIN was wrong, we really don't want to try that PIN
again automatically because it might lock the SIM. To ensure that
doesn't happen, disable autoconnect so that the user must manually
request reconnection.
(this doesn't fix auto-connect-with-a-wrong-PIN completely, as
autoconnect is reset when resuming from sleep, but it's a start)
Determining when the NMDeviceModem is available and when different
connections are available is easier if the modem's state is tracked,
instead of using the separate Enabled and Connected properties.
These properties could not accurately represent the SIM lock state
and prevented NetworkManager from making the modem available for
auto-activation when locked, even if a PIN was available.
In this new scheme, the NMDeviceModem is UNAVAILABLE when the
ModemManager modem state is FAILED, UNKNOWN, or INITIALIZING. It
transitions to the NM DISCONNECTED state when the modem has finished
initializing and has not failed.
Once the NMDeviceModem is in DISCONNECTED state it can be activated
even if the SIM is locked and a PIN is required; the PIN will be
requested when starting activation, either from the connection itself
or via a secrets request. This makes auto-activation of WWAN
connections possible.
This also allows us to consolidate code dealing with modem enable/disable
into the base NMModem class using the modem state, and to log more modem
information for debugging purposes.
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>
