Parsing can be complicated enough. It's simpler to just work
top-to-bottom, without calling various helper functions. This was,
you can see all the code in one place, without need to jump to
the helper function to see what it is doing.
In general, a static function that is only called once, does sometimes
not simplify but obfuscate the code.
The tests already honored the environment variable $NMTST_IFCFG_RH_UPDATE_EXPECTED
to indicate that the .cexpected files should be written by the tests.
However, in the meantime, we instead use NM_TEST_REGENERATE=1 at various
places for this purpose. Honor that flag as well.
When assuming existing connections, allow the same connection to be
activated on a different device if the connection is multi-connect
capable. Otherwise, when a connection is active on multiple devices
and NM is restarted, we assume only the first instance, and create
in-memory connections for others.
In general, a activatable connection is one that is currently not
active, or supports to be activatable multiple times according to
multi-connect setting. In addition, during autoconnect, a profile
which is marked as multi-connect=manual-multiple will not be avalable.
Hence, add an argument "for_auto_activation".
The code is mostly unused but will be used next (except for connections,
which set connection.multi-connect=multiple).
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
For dynamic IP methods (DHCP, IPv4LL, WWAN) the route metric is set at
activation/renewal time using the value from static configuration. To
support runtime change we need to update the dynamic configuration in
place and tell the DHCP client the new value to use for future
renewals.
https://bugzilla.redhat.com/show_bug.cgi?id=1528071
Some warnings depends on others: -Wformat-security won't work without
-Wformat. With -Wall we're confident enough that we have important
warnings enabled and in any case we're going to enable it anyway.
https://github.com/NetworkManager/NetworkManager/pull/175
g-ir-scanner uses distutils that have an unfortunate misfeature of
inheriting the compiler flags it itself was built with.
This includes the hardening flags that don't work with without
redhat-rpm-build and break with clang every full moon.
A configure check makes it clear about what went wrong in case
introspection is desired, otherwise turns it off.
(Taken from network-manager commit 678890ed0347849990787e8893122a39f95cb708)
This is a mere debugging convenience thing: e.g. if you run, but want to
check whether nm-applet or nmcli agent works fine, it's convenient that
the agent you run later gets a chance to deal with the secrets requests
first.
Is seems to do the job and is simpler that adding some more complicated
policy (e.g. introducing priorities or something).
https://github.com/NetworkManager/NetworkManager/pull/174
NM_SETTING_NAME is a special property that only has relevance
to libnm. It is inherited by all NMSetting instances. It is
read-only, and it has no corresponding value on D-Bus or nmcli.
Skip it during generate-setting-docs.py.
This also drops it from `man nm-settings`, where it doesn't belong.
Update the device state file every time the device is connected,
disconnected, or becomes unmanaged. In this way, NM becomes more
robust against crashes or forced terminations because it can resume
the previous device state seamlessly.
Rename nm_manager_write_device_state() to
nm_manager_write_device_state_all(), and split out the code to write a
single device state to a new function.
When the IPv4 method is 'auto' and there are static addresses
configured in the connection, start a DAD probe for the static
addresses and apply them immediately on success, without waiting for
DHCP to complete.
Note that if the static address is in the same subnet of the DHCP one,
when we add the DHCP address we want it to be primary and so we will
remove the static address temporarily to achieve the right order of
addresses.
https://bugzilla.redhat.com/show_bug.cgi?id=1369905
_nm_utils_init() is a __attribute__((constructor)) function,
that is, it runs during dlopen().
On the other head, g_module_open() itself calls dlopen().
It is prone to deadlock. Don't do it.
The check is only an aggressive assertion to crash the application
if it wrongly loads libnm and libnm-util/libnm-glib at the same time.
If that happens, all is lost already. We can just as well call the
assertion later. It's not supposed to fail anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=796804
Some properties in NetworkManager's D-Bus API are IPv4 addresses
in network byte order (big endian). That is problematic.
It is no problem, when the NetworkManager client runs on the same
host. That is the case with libnm, which does not support to be used
remotely for the time being.
It is a problem for an application that wants to access the D-Bus
interface of NetworkManager remotely. Possibly, such an application
would be implemented in two layers:
- one layer merely remotes D-Bus, without specific knowledge of
NetworkManager's API.
- a higher layer which accesses the remote D-Bus interface of NetworkManager.
Preferably it does so in an agnostic way, regardless of whether it runs
locally or remotely.
When using a D-Bus library, all accesses to 32 bit integers are in
native endianness (regardless of how the integer is actually encoded
on the lower layers). Likewise, D-Bus does not support annotating integer
types in non-native endianness. There is no way to annotate an integer
type "u" to be anything but native order.
That means, when remoting D-Bus at some point the endianness must be
corrected.
But by looking at the D-Bus introspection alone, it is not possible
to know which property need correction and which don't. One would need
to understand the meaning of the properties.
That makes it problematic, because the higher layer of the application,
which knows that the "Nameservers" property is supposed to be in network
order, might not easily know, whether it must correct for endianness.
Deprecate IP4Config properties that are only accessible with a particular
endianness, and add new properties that expose the same data in an
agnostic way.
Note that I added "WinsServerData" to be a plain "as", while
"NameserverData" is of type "aa{sv}". There is no particularly strong
reason for these choices, except that I could imagine that it could be
useful to expose additional information in the future about nameservers
(e.g. are they received via DHCP or manual configuration?). On the other
hand, WINS information likely won't get extended in the future.
Also note, libnm was not modified to use the new D-Bus fields. The
endianness issue is no problem for libnm, so there is little reason to
change it (at this point).
https://bugzilla.redhat.com/show_bug.cgi?id=1153559https://bugzilla.redhat.com/show_bug.cgi?id=1584584
nm_gobject_notify_together() freezes the notifications to emit both
notification signals together. That matters for NMDBusObject base
class, which hooks into dispatch_properties_changed() to emit a combined
"PropertiesChanged" signal.
Note, that during calls like nm_ip4_config_replace(), we already
froze/thawed the notifications. So, this change adds unnecessary
freeze/thaw calls, because signal emition is already frozen.
That is a bit ugly, because g_object_freeze_notify() is more heavy
than I'd wish it would be.
Anyway, for other places, like nm_ip4_config_reset_routes() that is
not the case. And correctness trumps performance.
Ultimately, the issue there is that we use NMIP4Config / NMIP6Config
both to track internal configuration, and to expose it on D-Bus.
The majority of created NMIP4Config / NMIP6Config instances won't get
exported, and but still pay an unnecessary overhead. The proper solution
to minimize the overhead would be, to separate these uses.
NM_GOBJECT_PROPERTIES_DEFINE() defines a helper function
_notify() to emit a GObject property changed notification.
Add another helper function to emit multiple notifications
together, and freeze/thaw the notification before.
This is particularly useful, because our D-Bus glue in
"nm-dbus-object.c" hooks into dispatch_properties_changed(),
to emit a combined PropertiesChanged signal for multiple
properties. By carefully freezing/thawing the notifications,
the exported objects can combine changes of multiple properties
in one D-Bus signal.
This helper is here to make that simpler.
Note that the compiler still has no problem to inline _notify()
entirey. So, in a non-debug build, there is little difference in
the generated code. It can even nicely inline calls like
nm_gobject_notify_together (self, PROP_ADDRESS_DATA,
PROP_ADDRESSES);
CC src/devices/ovs/src_devices_ovs_libnm_device_plugin_ovs_la-nm-device-ovs-bridge.lo
In file included from src/devices/ovs/nm-device-ovs-bridge.c:20:
In file included from ./shared/nm-default.h:307:
In file included from ./src/nm-logging.h:25:
./libnm-core/nm-core-types.h:28:10: fatal error: 'nm-core-enum-types.h' file not found
#include "nm-core-enum-types.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
CC src/settings/plugins/ifupdown/src_settings_plugins_ifupdown_libnms_ifupdown_core_la-nms-ifupdown-interface-parser.lo
In file included from src/settings/plugins/ifupdown/nms-ifupdown-interface-parser.c:23:
In file included from ./shared/nm-default.h:307:
In file included from ./src/nm-logging.h:25:
./libnm-core/nm-core-types.h:28:10: fatal error: 'nm-core-enum-types.h' file not found
#include "nm-core-enum-types.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:13904: src/settings/plugins/ifupdown/src_settings_plugins_ifupdown_libnms_ifupdown_core_la-nms-ifupdown-interface-parser.lo] Error 1
Utilize _nm_setting_to_dbus() to serialize the setting. The main reason
is that this way we can also print the more complicated values
g_strdup_value_contents() can't grok, e.g. the GArrays and GHashTables.
Some effort was spent on tidying up the results in a manner it was done
previously, instead of reducing this to a plain g_variant_print(). It
looks good that way:
Before:
vpn
service-type : "org.freedesktop.NetworkManager.VPN.Novpn" (s)
user-name : NULL (sd)
persistent : FALSE (sd)
data : ((GHashTable*) 0xc61060) (s)
secrets : ((GHashTable*) 0xdda640) (s)
timeout : 0 (sd)
After:
vpn
service-type : 'org.freedesktop.NetworkManager.VPN.Novpn'
data : {'gateway': 'novpn.example.com', 'username': 'hello'}
secrets : {'password': 'world'}
Note that no effort was spent on printing the defaults. There are
multiple ways that could be achieved, but I'm not sure it would be all
that necessary given this is really just a quick'n'dirty debugging facilty.
