Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
When delaying the deactivation of a device during dispatcher-pre-down,
we must preseve the reason to pass it on.
This is especially important, because nm_device_slave_notify_release()
checks for the reason, and does not deactivate the slave if no reason is
given. This error caused slaves the be left up when deactivating the master.
Also update the call to nm_device_slave_notify_release() to ensure we
have a valid state reason when configuring the slave. This would have
pointed out the issue and would even work around it.
Regression introduced by commit d00e2147de.
Signed-off-by: Thomas Haller <thaller@redhat.com>
On shutdown we can't defer the response to a callback, so we need to
use synchronous D-Bus calls. Second, sometimes we want to block on
the dispatcher response, like for pre-down.
The NMDevice dispose() function contained some badly-duplicated logic
about when to deactivate a device on its last ref. This logic should
only run when the device is removed by the manager, since the manager
controls the device's life-cycle, and the manager knows best when to
clean up the device. But since it was tied to the device's refcount,
it could have run later than the manager wanted, or not at all.
It gets better. Dispose duplicated logic that was already done in
nm_device_cleanup(), and then *called* nm_device_cleanup() if the
device was still activated and managed. But the manager already
unmanages the device when removing it, which triggers a call to
nm_device_cleanup(), takes the device down, and resets the IPv6
sysctl properties, which dispose() duplicated too. So by the time
dispose() runs, the device should already be unmanaged if the
manager wants to deconfigure it, and most of the dispose() code
should be a no-op.
Clean all that up and remove duplicated functions. Now, the flow
should be like this:
1) manager decides to remove the device and calls remove_device()
2) if the device should be deconfigured, the manager unmanages
the device
3) the NMDevice state change handler tears down the active connection
via nm_device_cleanup() and resets IPv6 sysctl properties
4) when the device's last reference is finally released, only internal
data members are freed in dispose() because the device should
already have been cleaned up by the manager and be unmanaged
5) if the device should be left running because it has an assumable
connection, then the device is not unmanaged, and no cleanup
happens in the state change handler or in dispose()
Ensure autoip4 is cleaned up when disposing, like we clean up DHCP.
Move things that only free stuff to finalize(), and move things that
unref stuff to dispose (eg, the Firewall Manager stuff).
dhcp6_cleanup() frees priv->dhcp6_ip6_config so dispose() doesn't need
to do that. Also use g_clear_object() when appropriate.
Lastly, notify that the DHCP4/6 config objects have changed *after*
clearing them, so that the PropertiesChanged signal is emitted with a
blank path to indicate the object is gone. Previously the PC signal
would have been emitted with the valid path of the DHCP4/6 config object,
but the object would already be dead.
For any function in nm-device.h which is not used outside of
nm-device.c, remove the public prototypes. Functions that
are actually used get moved above their caller, and functions
that have no callers are removed.
Move the GObject-related stuff to the bottom of the file and get
rid of no-longer-necessary forward prototypes since the stuff that
required those prototypes is now below the implementation.
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>
