GError codes are only unique per domain, so logging the code without
also indicating the domain is not helpful. And anyway, if the error
messages are not distinctive enough to tell the whole story then we
should fix the error messages.
Based-on-patch-by: Dan Winship <danw@gnome.org>
Functions that take a GError** MUST fill it in on error. There is no
need to check whether error is NULL if the function it was passed to
had a failing return value.
Likewise, a proper GError must have a non-NULL message, so there's no
need to double-check that either.
Based-on-patch-by: Dan Winship <danw@gnome.org>
There are far too many "flags". Rename the "flags" to "n_ifa_flags"
which reminds to "ifa_flags" in 'struct ifaddrmsg', but with a
distinctive "n_" prefix.
There are far too many "flags". Rename the "flags" to "n_ifi_flags"
which reminds to "ifi_flags" in 'struct ifinfomsg', but with a
distinctive "n_" prefix.
g_str_hash() can not be called with NULL. Ensure that we don't crash.
Thereby, refactor the hashing algorithm because the chassis-id and
port-id are small numbers and xor-ing can cancel them easily.
Don't rely on what's already on the device. It could be that the MAC address
set on the device is not meaningful -- the NM crashed while two devices were
teamed together and now they have the same hardware address and now it's
impossible to bond them with mode=5.
This saves 110 bytes (which is 1/29986680757 of the size of the books in the
Library of Congress).
Also, the function is static; not using the nm_device_ prefix is preferred.
This fixes the issue where all Ad-Hoc networks try to connect one after one on
NM startup instead of the managed network that has AP available.
Fixes: e2637760f1
Since commit 87a3df2e57, the unmanaged
flag NM_UNMANAGED_USER_SETTINGS could be overwritten via an explict
user decision (NM_UNMANAGED_USER_EXPLICIT).
It makes sense to allow user configuration from file to be changable
by an explict user action via D-Bus at runtime.
However, it also changes behavior for devices that are currently explicitly
managed. Previously, a reload of the NM_UNMANAGED_USER_SETTINGS would
immediately unmanaged the device:
- for keyfile: send SIGHUP to reload NetworkManager.conf
- for ifcfg-rh: `nmcli connection [re]load`
So this change in behavior could negatively affect users who rely
on being able to configure "NM_CONTROLLED=no" and expect to unmanaged
the device immediately. Thus revert the change.
Note that NM_UNMANAGED_USER_SETTINGS is anyway ugly and should be
deprecated:
- for keyfile, why having the option "keyfile.unmanaged-devices"
instead of a generic options?
- for ifcfg-rh, why put per-device configuration in a per-connection
file?
The preferred way is to configure NM_UNMANAGED_USER_UDEV via
"ENV{NM_UNMANAGED}". Maybe we should also add a new configuration
scheme via NetworkManager.conf.
https://bugzilla.gnome.org/show_bug.cgi?id=762331
The NM_UNMANAGED_USER_SETTINGS flags are determined by the settings plugins.
That is, either:
- keyfile's "unmanaged-devices" configuration option
- ifcfg-rh's "NM_CONTROLLED" option
- ifnet's "managed" option
Rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS to reflect
that it this is user configuration determined by the settings plugin.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
When the device is transitioning from unmanaged to disconnected for "assumed"
reason, bring_up is not called. This is not a good thing in numerous
instances, e.g.:
1.) vlans that we've created need that to set IFF_UP and read carrier
otherwise they won't be available for connections.
2.) veths that are being managed need to start the deferred carrier check
so that the behavior matches real Ethernet.
3.) Hardware devices that were plugged in while NetworkManager is running
that need the IFF_UP for a carrier check, possibly enqueueing a deferred one.
Fixes: 5637d72af2.
Like we already do for IPv6 addresses, we should expose addresses
in a defined, stable sort order.
Clients usually show the addresses in the same order as obtained
via D-Bus.
When executing these commands:
ip link add br0 type bridge
ip link set dev br0 up
ip link add dummy1 type dummy
ip link set dev dummy1 up
ip addr add 1.1.1.1/24 dev br0
brctl addif br0 dummy1
sleep 1
ip link del br0
ip link del dummy1
the following assertion was failing:
nm_device_master_release_one_slave: runtime check failed: (NM_FLAGS_HAS (slave_priv->unmanaged_mask, NM_UNMANAGED_IS_SLAVE))
#0 g_logv()
#1 g_log()
#2 g_warn_message()
#3 nm_device_master_release_one_slave()
#4 nm_device_cleanup()
#5 _set_state_full()
#6 nm_device_state_changed()
#7 nm_device_unrealize()
#8 _platform_link_cb_idle()
#9 g_main_context_dispatch()
#10 g_main_context_dispatch()
#11 g_main_context_iterate()
#12 g_main_loop_run()
#13 main()
Upon slave removal we unrealize the device, resetting the unmanaged
flags to NM_UNMANAGED_PLATFORM_INIT, then we clean up the device and
call nm_device_master_release_one_slave(), which asserts the presence
of NM_UNMANAGED_IS_SLAVE flag cleared just before.
Drop the check.
Fixes: 87a3df2e57
Factories that overwrite this function are not supposed to chain
up the parent implementation. Thus there is no reason to have
a default implementation and it's clearer to inline it.
We not only want to check the device name when creating a virtual device, but
also when determining if the connection can actually be activated there.
Otherwise the device names will mix up if there's more connections that use
virtual devices of the same type.
This breaks API and ABI for the functions related to Reapply,
which got introduced in the current 1.1 development phase.
The version-id is here to allow users to error out if the connection
on the device was changed by a concurrent action.
https://bugzilla.gnome.org/show_bug.cgi?id=761714
This field will be later used by NMDevice's Reapply and
GetAppliedConnection methods. The usecase is to first fetch
the currently applied connection, adjust it and reapply it.
Using the version-id, a concurrent modification can be detected
and Reapply can reject the invocation.
Otherwise, a tun device from external openvpn service will be managed by
NetworkManager.
<debug> [1455615148.716529] [devices/nm-device.c:9082] _set_unmanaged_flags(): [0x55e6f5756070] (tun7): unmanaged: flags set to [!sleeping,!loopback,!platform-init,!user-config,!external-down=0x0/0xa19/managed, set-managed [platform-init=0x10], reason managed, transition-state)
<info> (tun7): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Fixes: 87a3df2e57
Some drivers (or things outside NM like 'powertop') may turn powersave
on, so don't touch it unless explicitly configured by user.
To achieve this, add new 'default' and 'ignore' options; the former
can be used to fall back to a globally configured setting, while the
latter tells NM not to touch the current setting.
When 'default' is specified, a missing global default configuration is
equivalent to 'ignore'.
It is possible to enable Wi-Fi power saving for all connections by
dropping a file in /etc/NetworkManager/conf.d with the following
content:
[connection]
wifi.powersave=3
https://bugzilla.gnome.org/show_bug.cgi?id=760125
Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between
unmanaged flags, device state and managed property.
Previously, the NM_UNMANAGED_DEFAULT was special in that a device was
still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag
set and its state was managed. Thus, whether the device (state) was managed,
depended on the device state too.
Now, a device is considered managed (or unmanaged) based on the unmanaged
flags and realization state alone. At the same time, the device state
directly corresponds to the managed property of the device. Of course,
while changing the unmanaged flags, that invariant is shortly violated
until the state transistion is complete.
Introduce more unmanaged flags whereas some of them are non-authorative.
For example, the EXTERNAL_DOWN flag has only effect as long as the user
didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other
words, certain flags can render other flags ineffective. Whether the device
is considered managed depends on the flags but also at the explicitly unset flags.
In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored
(if no other flags were present).
Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected
state would transition back to unmanaged. No longer do that. Once a device is
managed, it stays managed as long as the flags indicate it should be managed.
However, the user can also modify the unmanaged flags via the D-Bus API.
Also get rid or nm_device_finish_init(). That was previously called
by NMManager after add_device(). As we now realize devices (possibly
multiple times) this should be handled during realization.
https://bugzilla.gnome.org/show_bug.cgi?id=746566
