The warning -Wstrict-prototypes was disabled by commit
db9b1df0e4 .
Enable it again, but avoid warnings for WiMax SDK by explicitly disabling the
compiler warning where needed.
Apparently clang does not produce a warning for -Wstrict-prototypes,
hence we don't need a clang specific #pragma.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_setting_verify() took a GSList of other NMSettings, but really it
would just be simpler all around to pass the NMConnection instead...
This means that several formerly NMSetting-branded functions that
operated on lists-of-settings now get replaced with
NMConnection-branded functions instead.
Add nm-core-types.h, typedefing all of the GObject types in
libnm-core; this is needed so that nm-setting.h can reference
NMConnection in addition to nm-connection.h referencing NMSetting.
Removing the cross-includes from the various headers causes lots of
fallout elsewhere. (In particular, nm-utils.h used to include
nm-connection.h, which included every setting header, so any file that
included nm-utils.h automatically got most of the rest of libnm-core
without needing to pay attention to specifics.) Fix this up by
including nm-core-internal.h from those files that are now missing
includes.
If the DHCP server happens to send "0.0.0.0", which you see with
some consumer gear that only has one nameserver set, don't warn
because we know it's bogus.
Also rename the copy & pasted 'searches' variable to what it's
actually used for.
Code outside of libnm-core/ should not include the private headers.
nm-core-internal.h should be used instead.
Fixes: 98fe073fb9
Signed-off-by: Thomas Haller <thaller@redhat.com>
This can be triggered by stopping the DBUS service. The assertion happens
because when the supplicant stops (due to the name-owner-change, which is triggered
because dbus-daemon quit), the supplicant manager sets all supplicant interfaces
to DOWN state so that they can be cleaned up. That does two things:
1) calls supplicant_interface_acquire() to attempt to re-launch wpa_supplicant
in case wpa_supplicant segfaulted
2) moves the NMDevicWifi to UNAVAILABLE state because the supplicant is gone,
the device is no longer usable and we must terminate the connection and wait
for the supplicant to come back
But #2 also ends up calling supplicant_interface_acquire(), because that's what
we want to do when the NMDeviceWifi is first managed (at startup) and when the
supplicant dies. The code just doesn't differentiate between the two cases.
To fix this, just allow duplicate "waiting for supplicant" pending
actions, which is fine because the operation doesn't care about strict
added/removed sequencing.
#0 0x000000381d0504e9 in g_logv (log_domain=0x59cd5b "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff8cccc1a0) at gmessages.c:989
#1 0x000000381d05063f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x000000000044f53b in nm_device_add_pending_action (self=0xa60310, action=0x7febecd1d37d "waiting for supplicant", assert_not_yet_pending=1) at devices/nm-device.c:6466
#3 0x00007febecd0bc56 in supplicant_interface_acquire (self=0xa60310) at nm-device-wifi.c:262
#4 0x00007febecd0b240 in device_state_changed (device=0xa60310, new_state=NM_DEVICE_STATE_UNAVAILABLE, old_state=NM_DEVICE_STATE_ACTIVATED, reason=NM_DEVICE_STATE_REASON_SUPPLICANT_FAILED) at nm-device-wifi.c:3136
#5 0x000000381dc05d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#6 0x000000381dc056bc in ffi_call (cif=cif@entry=0x7fff8cccc6c0, fn=0x7febecd0b050 <device_state_changed>, rvalue=0x7fff8cccc630, avalue=avalue@entry=0x7fff8cccc5b0) at ../src/x86/ffi64.c:522
#7 0x000000381e010ad8 in g_cclosure_marshal_generic (closure=0xa30a40, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>,
marshal_data=0x7febecd0b050 <device_state_changed>) at gclosure.c:1454
#8 0x000000381e010298 in g_closure_invoke (closure=closure@entry=0xa30a40, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff8cccc8c0, invocation_hint=invocation_hint@entry=0x7fff8cccc860)
at gclosure.c:777
#9 0x000000381e02211b in signal_emit_unlocked_R (node=node@entry=0xa322b0, detail=detail@entry=0, instance=instance@entry=0xa60310, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff8cccc8c0) at gsignal.c:3624
#10 0x000000381e02a0f2 in g_signal_emit_valist (instance=instance@entry=0xa60310, signal_id=signal_id@entry=63, detail=detail@entry=0, var_args=var_args@entry=0x7fff8ccccaf8) at gsignal.c:3330
#11 0x000000381e02a8f8 in g_signal_emit_by_name (instance=0xa60310, detailed_signal=0x59a8d1 "state-changed") at gsignal.c:3426
#12 0x00000000004514a4 in _set_state_full (self=0xa60310, state=NM_DEVICE_STATE_UNAVAILABLE, reason=NM_DEVICE_STATE_REASON_SUPPLICANT_FAILED, quitting=0) at devices/nm-device.c:6820
#13 0x0000000000449ec6 in nm_device_state_changed (self=0xa60310, state=NM_DEVICE_STATE_UNAVAILABLE, reason=NM_DEVICE_STATE_REASON_SUPPLICANT_FAILED) at devices/nm-device.c:6949
#14 0x00007febecd0f247 in supplicant_iface_state_cb (iface=0x9b9290, new_state=13, old_state=12, disconnect_reason=0, user_data=0xa60310) at nm-device-wifi.c:2276
#15 0x000000381dc05d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#16 0x000000381dc056bc in ffi_call (cif=cif@entry=0x7fff8cccd230, fn=0x7febecd0eb20 <supplicant_iface_state_cb>, rvalue=0x7fff8cccd160, avalue=avalue@entry=0x7fff8cccd0e0) at ../src/x86/ffi64.c:522
#17 0x000000381e010f35 in g_cclosure_marshal_generic_va (closure=0xa2f490, return_value=0x0, instance=0x9b9290, args_list=<optimized out>, marshal_data=0x0, n_params=3, param_types=0xa422e0) at gclosure.c:1550
#18 0x000000381e0104c7 in _g_closure_invoke_va (closure=closure@entry=0xa2f490, return_value=return_value@entry=0x0, instance=instance@entry=0x9b9290, args=args@entry=0x7fff8cccd470, n_params=3, param_types=0xa422e0) at gclosure.c:840
#19 0x000000381e029749 in g_signal_emit_valist (instance=0x9b9290, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fff8cccd470) at gsignal.c:3238
#20 0x000000381e02a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#21 0x00000000004b0e4b in set_state (self=0x9b9290, new_state=13) at supplicant-manager/nm-supplicant-interface.c:344
#22 0x00000000004b0916 in smgr_avail_cb (smgr=0xa3c890, pspec=0xa3c8d0, user_data=0x9b9290) at supplicant-manager/nm-supplicant-interface.c:930
#23 0x000000381e010298 in g_closure_invoke (closure=0x9a68b0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fff8cccd770, invocation_hint=invocation_hint@entry=0x7fff8cccd710) at gclosure.c:777
#24 0x000000381e02235d in signal_emit_unlocked_R (node=node@entry=0x990da0, detail=detail@entry=610, instance=instance@entry=0xa3c890, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff8cccd770) at gsignal.c:3586
#25 0x000000381e02a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff8cccd900) at gsignal.c:3330
#26 0x000000381e02a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#27 0x000000381e014945 in g_object_dispatch_properties_changed (object=0xa3c890, n_pspecs=1, pspecs=0x0) at gobject.c:1047
#28 0x000000381e017019 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0xa3c890) at gobject.c:1141
#29 g_object_notify (object=0xa3c890, property_name=<optimized out>) at gobject.c:1183
#30 0x00000000004b56f1 in set_running (self=0xa3c890, now_running=0) at supplicant-manager/nm-supplicant-manager.c:228
#31 0x00000000004b5002 in name_owner_changed (dbus_mgr=0x99f740, name=0x9ba910 "fi.w1.wpa_supplicant1", old_owner=0xa945a0 ":1.25", new_owner=0xac2ce0 "", user_data=0xa3c890) at supplicant-manager/nm-supplicant-manager.c:294
#32 0x000000381dc05d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#33 0x000000381dc056bc in ffi_call (cif=cif@entry=0x7fff8cccdd10, fn=0x4b4d50 <name_owner_changed>, rvalue=0x7fff8cccdc80, avalue=avalue@entry=0x7fff8cccdc00) at ../src/x86/ffi64.c:522
#34 0x000000381e010ad8 in g_cclosure_marshal_generic (closure=0xa530a0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#35 0x000000381e010298 in g_closure_invoke (closure=0xa530a0, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff8cccdf10, invocation_hint=invocation_hint@entry=0x7fff8cccdeb0) at gclosure.c:777
#36 0x000000381e02235d in signal_emit_unlocked_R (node=node@entry=0x99cce0, detail=detail@entry=0, instance=instance@entry=0x99f740, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff8cccdf10) at gsignal.c:3586
#37 0x000000381e02a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff8ccce0d0) at gsignal.c:3330
#38 0x000000381e02a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#39 0x00000000004c4026 in proxy_name_owner_changed (proxy=0x998210, name=0xa3ad50 "fi.w1.wpa_supplicant1", old_owner=0x9cffc0 ":1.25", new_owner=0x99d230 "", user_data=0x99f740) at nm-dbus-manager.c:708
#40 0x000000381dc05d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#41 0x000000381dc056bc in ffi_call (cif=cif@entry=0x7fff8ccce410, fn=0x4c3fd0 <proxy_name_owner_changed>, rvalue=0x7fff8ccce380, avalue=avalue@entry=0x7fff8ccce300) at ../src/x86/ffi64.c:522
#42 0x000000381e010ad8 in g_cclosure_marshal_generic (closure=closure@entry=0x9beb80, return_gvalue=return_gvalue@entry=0x0, n_param_values=<optimized out>, param_values=<optimized out>,
invocation_hint=invocation_hint@entry=0x7fff8ccce630, marshal_data=marshal_data@entry=0x0) at gclosure.c:1454
#43 0x0000003829a10864 in marshal_dbus_message_to_g_marshaller (closure=0x9beb80, return_value=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=0x7fff8ccce630, marshal_data=0x0) at dbus-gproxy.c:1736
#44 0x000000381e010298 in g_closure_invoke (closure=0x9beb80, return_value=return_value@entry=0x0, n_param_values=3, param_values=param_values@entry=0x7fff8ccce690, invocation_hint=invocation_hint@entry=0x7fff8ccce630) at gclosure.c:777
#45 0x000000381e02235d in signal_emit_unlocked_R (node=node@entry=0x9be290, detail=detail@entry=347, instance=instance@entry=0x998210, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff8ccce690) at gsignal.c:3586
#46 0x000000381e02a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff8ccce840) at gsignal.c:3330
#47 0x000000381e02a3af in g_signal_emit (instance=instance@entry=0x998210, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#48 0x0000003829a111c0 in dbus_g_proxy_emit_remote_signal (message=0xa6c2b0, proxy=0x998210) at dbus-gproxy.c:1789
#49 dbus_g_proxy_manager_filter (connection=<optimized out>, message=0xa6c2b0, user_data=0x9be520) at dbus-gproxy.c:1356
#50 0x000000382001006e in dbus_connection_dispatch (connection=connection@entry=0x9badb0) at dbus-connection.c:4631
#51 0x0000003829a0ad65 in message_queue_dispatch (source=source@entry=0x9bdcc0, callback=<optimized out>, user_data=<optimized out>) at dbus-gmain.c:90
#52 0x000000381d0492a6 in g_main_dispatch (context=0x99b4b0) at gmain.c:3066
#53 g_main_context_dispatch (context=context@entry=0x99b4b0) at gmain.c:3642
#54 0x000000381d049628 in g_main_context_iterate (context=0x99b4b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#55 0x000000381d049a3a in g_main_loop_run (loop=0x99b5d0) at gmain.c:3907
#56 0x0000000000443c28 in main (argc=1, argv=0x7fff8cccf268) at main.c:704
Signed-off-by: Thomas Haller <thaller@redhat.com>
Calling dbus_g_proxy_begin_call() on a closed DBUS connection will
return NULL. All the call sites of nm_call_store_add() don't check
for NULL and therefore might hit an assertion.
This can easily reproduced by stopping the DBUS daemon.
Backtrace:
#0 0x000000381d0504e9 in g_logv (log_domain=0x59cd8b "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff42cce5c0) at gmessages.c:989
#1 0x000000381d05063f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00000000004b64e9 in nm_call_store_add (store=0x7f8e1c003d20, proxy=0x219c0d0, call=0x0) at supplicant-manager/nm-call-store.c:47
#3 0x00000000004b0b7b in interface_add (self=0x20e2500, is_wireless=1) at supplicant-manager/nm-supplicant-interface.c:907
#4 0x00000000004b0865 in nm_supplicant_interface_new (smgr=0x216c870, ifname=0x211e840 "wlp3s0", is_wireless=1, fast_supported=1, ap_support=AP_SUPPORT_YES, start_now=1) at supplicant-manager/nm-supplicant-interface.c:1355
#5 0x00000000004b47da in nm_supplicant_manager_iface_get (self=0x216c870, ifname=0x211e840 "wlp3s0", is_wireless=1) at supplicant-manager/nm-supplicant-manager.c:91
#6 0x00007f8e250f8b3f in supplicant_interface_acquire (self=0x218a350) at nm-device-wifi.c:253
#7 0x00007f8e250fc22e in supplicant_iface_state_cb (iface=0x20e2290, new_state=13, old_state=9, disconnect_reason=0, user_data=0x218a350) at nm-device-wifi.c:2274
#8 0x000000381dc05d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#9 0x000000381dc056bc in ffi_call (cif=cif@entry=0x7fff42cced00, fn=0x7f8e250fbb20 <supplicant_iface_state_cb>, rvalue=0x7fff42ccec30, avalue=avalue@entry=0x7fff42ccebb0) at ../src/x86/ffi64.c:522
#10 0x000000381e010f35 in g_cclosure_marshal_generic_va (closure=0x20fd2b0, return_value=0x0, instance=0x20e2290, args_list=<optimized out>, marshal_data=0x0, n_params=3, param_types=0x2189ee0) at gclosure.c:1550
#11 0x000000381e0104c7 in _g_closure_invoke_va (closure=closure@entry=0x20fd2b0, return_value=return_value@entry=0x0, instance=instance@entry=0x20e2290, args=args@entry=0x7fff42ccef40, n_params=3, param_types=0x2189ee0)
at gclosure.c:840
#12 0x000000381e029749 in g_signal_emit_valist (instance=0x20e2290, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fff42ccef40) at gsignal.c:3238
#13 0x000000381e02a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#14 0x00000000004b0e4b in set_state (self=0x20e2290, new_state=13) at supplicant-manager/nm-supplicant-interface.c:344
Signed-off-by: Thomas Haller <thaller@redhat.com>
Ignoring SIGPIPE signal, otherwise it causes problems.
For example, running `NetworkManager --debug 2>&1 | tee log.txt` in a
terminal and killing it with CTRL+C (SIGINT), will abruplty terminate
NetworkManager without clean shutdown.
Note, that with this patch and above example, NetworkManager will both
receive SIGINT and SIGPIPE. Since we now ignore SIGPIPE, NetworkManager
will shut down cleanly. Any logging output after killing `tee` is of
lost however.
Also, there might be other cases where NM reads/writes to a pipe/socket
and unexpectedly received SIGPIPE. For example nm-dns-manager.c
spawns netconfig (run_netconfig()) and writes the configuration
to its stdin. If netconfig dies, the write might fail with EPIPE.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since 3a54d050 the AP address is not a gbyte[], but a char *. The fake AP BSSID
fixup could trigger an assertion failure:
Oct 26 11:14:45 goatlord.localdomain NetworkManager[540]: nm_ethernet_address_is_valid: assertion 'addr != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=739258
Fixes: 3a54d05098
Previously the only thing preventing default-unmanaged devices from
being auto-activated was luck and the fact that they didn't have any
available connections when in the UNMANAGED state. That's no longer
true, so we must be more explicit about their behavior.
Furthermore it makes no sense to allow default-unmanaged devices
to set priv->autoconnect=TRUE since that is never supposed to
happen, so enforce that both in NM itself and if the change
request comes in over the D-Bus interface.
Lastly, internal priv->autoconnect=TRUE changes never emitted a
property change notification, meaning the NMPolicy would never
schedule an autoconnect check if the device's priv->autoconnect
was set to TRUE as a result of re-activating or waking from sleep.
Previously a master device would wait for a carrier before starting
IP configuration only for 'manual' connections, but that's not quite
broad enough. We also want to allow SHARED methods to proceed
immediately since they are also effectively static/manual configuration.
Use the newly split out methods for checking whether a connection
requires a carrier or not to allow the SHARED method to proceed
for master devices without a carrier.
For example, this allows bridge configurations with tun/tap ports
to set up SHARED addressing before the tun/tap gets a carrier which
only happens when something opens the other side of the tun/tap
(like the VM or container).
Default unmanaged devices become managed when the user explicitly activated
a connection on the device, but the user can't do that unless the device
has some available connections. Fix things up so that default unmanaged
devices can have available connections.
When checking whether the dhcp-client-identifier is a hex string,
we expected pairs of hexadecimal digits separated by colon.
Relax this check to also allow single hex digits.
https://bugzilla.gnome.org/show_bug.cgi?id=737727
Signed-off-by: Thomas Haller <thaller@redhat.com>
This will provide an extremely easy way for applications to find out
what type of connection the system is currently using. They might want
to do this to avoid using data if a phone is on a 3G connection, for
example.
Having this as a separate property provides at least two advantages:
1) it reduces code complexity for those wanting only this one simple
piece of information
2) we could allow access to this property (but nothing else) to
privilege-separated applications in the future
This patch adds the missing nm_active_connection_get_connection_type()
which was in the header file but never actually implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=739080
Creating a mode=ap connection (as GNOME control center does) would otherwise
assert in complete_connection despite having a proper SSID set:
NetworkManager-wifi:ERROR:nm-device-wifi.c:1118:complete_connection: assertion failed: (ssid)
Aborted
It no longer exists.
Also, the special case of ENOENT handling in nm-session-monitor-ck is removed;
it's not worth keeping it around just to print a log message when the error is
ignored nayway.
A number of classes in core had their own error domains that aren't
really necessary.
In the case of NMDcbError, NMDhcpManagerError, NMDnsManagerError,
NMDnsmasqManagerError, NMPppManagerError, and NMSessionMonitorError,
most of the codes they defined weren't even being used, and at any
rate, the errors were always returned into contexts where they would
just have their message extracted and then get thrown away without
anyone ever looking at the domain or code. So all uses of those
domains can just be replaced with NM_MANAGER_ERROR_FAILED without any
loss of information.
NMAuthManagerError only had 1 error code, and it just indicated
"something went wrong", so it can be replaced with
NM_MANAGER_ERROR_FAILED without loss of information.
(nm-auth-manager.c has also been fixed to return
NM_MANAGER_ERROR_FAILED when the CheckAuthorization D-Bus call fails,
rather than returning whatever error domain/code the D-Bus call
returned.)
NMVpnManagerError used 2 of its 4 error codes, and they could actually
end up getting returned across D-Bus in some cases. But there are
NMManagerError codes that are semantically similar enough to make the
NMVpnManagerError ones unnecessary.
Each plugin defined its own error domain, though none actually defined
any errors. Replace these with appropriate uses of
NM_SETTINGS_ERROR_INVALID_CONNECTION and NM_SETTINGS_ERROR_FAILED.
Move the definition of NMSettingsError to nm-errors, register it with
D-Bus, and verify in the tests that it maps correctly.
Remove a few unused error codes, simplify a few others, and rename
GENERAL to FAILED and HOSTNAME_INVALID to INVALID_HOSTNAME, for
consistency.
NMManagerError has other operation-specific errors (like
NM_MANAGER_ERROR_ALREADY_ASLEEP_OR_AWAKE), so it makes sense to move
NM_LOGGING_ERROR_UNKNOWN_LEVEL and NM_LOGGING_ERROR_UNKNOWN_DOMAIN
there too rather than having them in their own tiny error domain.
Move the definition of NMManagerError to nm-errors, register it with
D-Bus, and verify in the tests that it maps correctly.
NM_MANAGER_ERROR_INTERNAL gets renamed to NM_MANAGER_ERROR_FAILED for
consistency. NM_MANAGER_ERROR_UNMANAGED_DEVICE is dropped since that
name doesn't really describe the one place it was previously used in.
NM_MANAGER_ERROR_SYSTEM_CONNECTION is dropped because it was't being
used. NM_MANAGER_ERROR_UNSUPPORTED_CONNECTION_TYPE is dropped because
it can be replaced with an NM_CONNECTION_ERROR.
NM_MANAGER_ERROR_AUTOCONNECT_NOT_ALLOWED is turned into the more
generic NM_MANAGER_ERROR_CONNECTION_NOT_AVAILABLE.
Also, remove the <tp:possible-errors> sections from nm-manager.xml,
since they were completely out of date.
Most NMDevice types defined their own error domain but then never used
it. A few did use their errors, but some of those errors are redundant
with NMDeviceError, and others can be added to it.
Merge libnm's NMDeviceError and the daemon's NMDeviceError into a
single enum (in nm-errors.h). Register the domain with D-Bus, and add
a test that the client side decodes it correctly.
The daemon's NM_DEVICE_ERROR_CONNECTION_INVALID gets absorbed into
libnm's NM_DEVICE_ERROR_INVALID_CONNECTION, and
NM_DEVICE_ERROR_UNSUPPORTED_DEVICE_TYPE gets dropped, since it was
only returned from one place, which is now using
NM_DEVICE_ERROR_FAILED, since (a) it ought to be a "can't happen", and
(b) the only caller of that function just logs error->message and then
frees the error without ever looking at the code.
Register NMConnectionError with D-Bus on both sides, so that, eg,
connection validation failures in the daemon will translate to the
correct error codes in the client.
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
nm_setting_lookup_type_by_quark() was only ever used in places that
were still mistakenly assuming the old style of nm_connection_verify()
errors, where the error message would contain only a property name and
no further explanation. Fix those places to assume that the error will
contain a real error message, and include both the setting name and
the property name.
Given that, there's no longer any need for
nm_setting_lookup_type_by_quark(), so drop it.
The IPv6LL address handling in userspace patches failed to handle the
case where the IPv6 method was 'ignore'. Previously the kernel would
usually add the IPv6LL address itself, but if NM has turned off kernel
IPv6LL then obviously this wouldn't happen. So when the method is
'ignore', turn off userspace IPv6LL handling and bounce disable_ipv6
to make the kernel add the IPv6LL address if it wants to.
NMActiveConnections start out in state "unknown", but then quickly
switch to "activating". Unfortunately, it's sometimes possible for
this to be externally visible. Fix this by lying and saying that state
is "activating" during the initial "unknown" stage (though not if the
state changes to "unknown" later on).
(Actually changing the initial state to "activating" breaks things
because some code depends on there being a transition into the
"activating" state.)
Routing configuration fails to apply if the device is not IFF_UP, so if
we're going to apply IP configuration to the device, make sure it's IFF_UP
first.
https://bugzilla.gnome.org/show_bug.cgi?id=738479
When a child device is found and an IP configuration already exists
for it even though it is under NM control (like when pppd applies
IP config to a WWAN device before NM gets the IP details from the pppd
plugin), don't deconfigure the child device when removing it from the
device list, because this breaks the device's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=738479
A generated connection contains a copy of the device's existing
configuration, so it's entirely redundant to merge the connection
back into the device's IP config. But even though that should
result in no changes to the IP config, NMSettingIPxConfig treats a
route metric of '0' as the device priority, while NMIPxConfig
allows 0 as a valid route metric. Since the setting values
are preferred (they are supposed to be user-supplied and thus
override anythign else, but in this case they are generated and
thus not user-supplied) external routes with a metric of 0 are
overwritten with the device priority metric.
https://bugzilla.gnome.org/show_bug.cgi?id=738268
