Hostname management is complicated. At least, how it is implemented currently.
For example, NMPolicy also sets the hostname (NMPolicy calls
nm_settings_set_transient_hostname() to have hostnamed set the hostname,
but then falls back to sethostname() in settings_set_hostname_cb()).
Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and
NMPolicy listens to changes from there -- instead of changes from
NMSettings.
Eventually, NMHostnameManager should contain the hostname parts from NMSettings
and NMPolicy.
- anticipate missing callback/ctx->result
- always invoke the result callback when given
- fix leaking GVariant in disconnect_done()
- fix crash due to non-initialized ctx->result
- pass cancellable to g_dbus_proxy_call()
And some fixes:
- proxy creation may fail. Don't handle it by retrying,
but at least don't access the invalid proxy instance.
- quering "DefaultAdapter" did not take a reference to @self
nor was the operation cancellable. This leads to crash
if the instance gets destroyed early.
And some fixes:
- proxy creation may fail. Don't handle it by retrying,
but at least don't access the invalid proxy instance.
- get_properties_cb() did not take a reference to @self
nor was the operation cancellable. This leads to crash
if the instance gets destroyed early.
Fix two issues of the previous code:
- the D-Bus proxy for the modem manager should not get created
synchronously.
- NMModemManager is a singleton, let it track the name-owner
change and the D-Bus proxy, instead of having one per NMDeviceBt.
Don't do non-trivial initialization in nm_device_bt_init(). At
this point, the object is not yet fully created. As we already have
a constructed() implemented, move the initialization there.
Also, bluetooth plugin uses NMModem from the wwan plugin. Don't
include such a foreign header in a "nm-device-bt.h". Instead, forward
declare what we need.
Most of the functions are strictly related to ModemManager. Their
name should hint to that, so that they are clearly separated from
the ofono functions and general purpose functions.
Same for data fields.
It is often wrong to take a reference to keep the instance alive during
the asynchronous request, because it means the instance cannot be
destroyed as long as the (non cancellable) request is bending.
Fix that for NMModemManager and pass a cancallable along.
libcurl employs some typechecking via "curl/typecheck-gcc.h". When
compling with --enable-lto, compilation fails otherwise with:
make[2]: Entering directory '/data/src/NetworkManager'
CC src/src_libNetworkManager_la-nm-connectivity.lo
CCLD src/libNetworkManager.la
CCLD src/libNetworkManagerTest.la
CCLD src/dhcp/tests/test-dhcp-dhclient
src/nm-connectivity.c: In function 'curl_check_connectivity':
src/nm-connectivity.c:147:10: error: call to '_curl_easy_getinfo_err_string' declared with attribute warning: curl_easy_getinfo expects a pointer to char * for this info [-Werror]
eret = curl_easy_getinfo (msg->easy_handle, CURLINFO_PRIVATE, &cb_data);
^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: /usr/bin/gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
For manged=unknown, we don't write the value to the
device state keyfile. The results in an empty file,
or at least, a keyfile that doesn't have device.managed
set.
On read, we must treat a missing device.managed flag as
unknown, and not as unmanaged. Otherwise, on restart
a device becomes marked as explicitly unmanaged.
This was broken by commit 142ebb1 "core: only persist explicit managed
state in device's state file", where we started conditionally
to no longer write the managed state.
Reported-by: Michael Biebl <mbiebl@debian.org>
Fixes: 142ebb1037
- print string value instead of numerical "managed"
- for missing state, print the same format. After all,
some defaults apply and it is interesting to know what
they are.
- config->removed can be replaced by c_list_is_empty(&config->lst)
- downgrade some assertions to nm_assert(). Even without the
assert we crash a few lines later with a NULL pointer access.
That gives almost the same debuggability and discoverability
of the bug.
- use exact type signature for GAsyncReadyCallback and avoid
casting.
- when the name owner disappears, cancel all asynchronous
operations. Note how the new pacrunner instance will anyway
start without configuration, so for all intended purpose, all
pending operations are at that moment obsolete.
We must not cancel pacrunner_cancellable when the D-Bus proxy is
created. Instead, keep it around and use it later for the asynchronous
D-Bus operations.
This doesn't really matter at the moment, because the pacrunner manager
is only destroyed when NetworkManager is about to terminated. That is
the only time when we actually cancel the asynchronous request. Also,
at that time we no longer iterate the mainloop, so the pending requests
are never completed anyway.
We listen to all RTM_GETLINK messages to get updates on interfaces statuses.
Unfortunately wireless code in the kernel sends those messages with wireless information included
and all other information excluded. When we receive such message we wipe out our valid cached entry
with new object that is almost empty because netlink message didn't contain any information.
Solution to this is to check that incoming message contains MTU field: this field is always
set for complete messages about interfaces and is not set by wireless code.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
https://github.com/NetworkManager/NetworkManager/pull/17
We autodetect systemd-resolved based on whether /etc/resolv.conf points
to one of the well known files of systemd-resolved.
Extend the check by also
- follow symlinks and compare the absolute link target
- open the file and compare the inodes for hard-linking
Note that when NetworkManager starts, systemd-resolved might not
have started yet. So, while comparing the inode is the best check,
we also compare symlinks (g_file_read_link() and realpath()).
Based-on-patch-by: Sam Morris <sam@robots.org.uk>
https://github.com/NetworkManager/NetworkManager/pull/16https://bugzilla.gnome.org/show_bug.cgi?id=779269
../../src/nm-firewall-manager.c: In function ‘_handle_dbus_start’:
../../src/nm-firewall-manager.c:318:2: error: ‘dbus_method’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_dbus_proxy_call (priv->proxy,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dbus_method,
~~~~~~~~~~~~
arg,
~~~~
Fixes: d8bf05d3e6
It's not the correct thing to do, but is the same behavior we've done
previously.
DAD is not even going to start until there's carrier and the client would
just wait indefinitely. Ideally, the client would choose not to waiat, but
it currently there's no way the client would discover what is going on.
https://bugzilla.redhat.com/show_bug.cgi?id=1446367
Commit #acf1067a allowed to assume connections on already managed
devices. Anyway, in complex scenario with layered connections, during
the startup of NetworkManager, this could interfere with the connection
assumption based on saved state.
So, avoid to re-assume connections on already managed devices during
startup.
Fixes: acf1067a45
Set the @was_active flag for external activations with DHCP, so that
DHCP is retried multiple times in case of failure, as we do for
managed connections when the lease expires and for assumed
connections.
Fixes test: renewal_gw_after_dhcp_outage_for_assumed_var1
Fixes: e3113fdc4b
We check the return value of _get_stable_id(); when it is NULL
priv->ndisc would stay NULL too and we would crash when dereferencing
@error.
Actually, _get_stable_id() can never return NULL, so replace the check
with an assertion.
src/devices/nm-device-ip-tunnel.c:257:8: warning: Branch condition evaluates to a garbage value
if (local4)
^~~~~~
src/devices/nm-device-ip-tunnel.c:264:8: warning: Branch condition evaluates to a garbage value
if (remote4)
^~~~~~~
Most of the IPv6 methods require a non-tentative link local address
configured on the interface; we look at priv->ip6_config to determine
if such address exist. If the configuration is out-of-sync, we may
proceed with configuration when the link-local address does not exist
or is still tentative, especially because we toggle the "disable_ipv6"
sysctl parameter just before, which clears all IPv6 addresses on the
interface.
Ensure that priv->ext_ip6_config_captured is up-to-date before
continuing with the IPv6 configuration, and use it to determine
whether suitable addresses are present.
Fixes test: @ipv6_set_ra_announced_mtu
Fixes: 8f4caab601
update_ip6_config() also removes addresses and routes no longer
present externally from the configuration, so it can't be called
before the changes are committed.
This reverts commit 8f4caab601.
The user data values are encoded in shell variables named
prefix "NM_USER_". The variable name is an encoded form of the
data key, consisting only of upper-case letters, digits, and underscore.
The alternative would be something like
NM_USER_1_KEY=my.keys.1
NM_USER_1_VAL='some value'
NM_USER_2_KEY=my.other.KEY.42
NM_USER_2_VAL='other value'
contary to
NM_USER_MY__KEYS__1='some value'
NM_USER_MY__OTHER___K_E_Y__42='other value'
The advantage of the former, numbered scheme is that it may be easier to
find the key of a user-data entry. With the current implementation, the
shell script would have to decode the key, like the ifcfg-rh plugin
does.
However, user data keys are opaque identifers for values. Usually, you
are not concerned with a certain name of the key, you already know it.
Hence, you don't need to write a shell script to decode the key name,
instead, you can use it directly:
if [ -z ${NM_USER_MY__OTHER___K_E_Y__42+x} ]; then
do_something_with_key "$NM_USER_MY__OTHER___K_E_Y__42"
fi
Otherwise, you'd first have to search write a shell script to search
for the interesting key -- in this example "$NM_USER_2_KEY", before being
able to access the value "$NM_USER_2_VAL".
