Add a new 'match' setting containing properties to match a connection
to devices. At the moment only the interface-name property is present
and, contrary to connection.interface-name, it allows the use of
wildcards.
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
"nm-autoptr.h" is done in a way that allows you to copy the header
in your source tree to support older versions of libnm, that didn't
contain the header yet. For example, we might want to use it in
network-manager-applet, but we don't want to bump the libnm dependency
to 1.11.2+ only to get this functionality.
Note that G_DEFINE_AUTOPTR_CLEANUP_FUNC() was added in glib 2.43.4,
and requires compiler support for the cleanup attribute. The compiler
support is taken as given, because we rely on it already. However,
NetworkManager and network-manager-applet still don't depend on a glib
version recent enough to provide these macros. To actually use them
(*inside*) NetworkManager/network-manager-applet, we either would have
to bump the glib minimal dependency, or reimplement g_autoptr in
/shared/nm-utils/nm-glib.h compat header.
https://bugzilla.gnome.org/show_bug.cgi?id=794294
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
libnm-core has been expanded to include proxy settings which clients
like nmcli, nm-connection-editor use to configure proxy in PacRunner. It
offers three modes i.e 'auto', 'manual'and 'none' and accordingly take
data to configure PacRunner. The modes matches on the PacRunner side too.
"nm-vpn-service-plugin.h" includes "nm-connection.h", so there is already no
way to use "nm-vpn-service-plugin.h" without also pulling in all "NetworkManager.h".
On the other hand, we might not include "nm-vpn-service-plugin.h" in
"NetworkManager.h" to keep the overall headers small (by default).
But let's just include it too. We already opted for convenience
over small-include by having one top-level header file.
Add a generic NMSettingTunnel which describes properties of tunnels
over IPv4 and IPv6 (GRE, SIT, IPIP, IPIP6, IP6GRE, etc.). Since those
tunnel types all have similar properties it makes sense to have a
single setting type for them.
Split the content of libnm/nm-vpn-editor-plugin.h and
move NMVpnEditorPlugin to libnm-core/nm-vpn-editor-plugin.h.
VPN plugins allow us to extend functionality about VPNs.
This can be also useful for NetworkManager core, hence
move that part to libnm-core.
The name NMVpnEditorPlugin is slightly misleading but not completely
wrong. The "editor" part stands no longer for bringing nm-applet
functionality (alone), but enable general VPN functionality in
the client.
Especially because we already have NMVpnPluginOld with a different
meaning (i.e. a base class of the plugin server implementation).
NMVpnPluginInfo is little more then a wrapper around
the GKeyFile that describes the VPN plugin settings,
i.e. the name files under "/etc/NetworkManager/VPN/".
Add this class to make the VPN API more explicit. Clients
now can use NMVpnPluginInfo instead of concerning themselves
with loading the keyfile and the meaning of its properties.
Also add support for a new VPN plugins directory
"/usr/lib/NetworkManager/VPN", which should replace
"/etc/NetworkManager/VPN" in the future. But we have to
consider both locations for backward compatibility.
The content of the VPN directory is not user configuration,
hence it should not be under "/etc". See related bug 738853.
Rename NMVpnPluginUiInterface to NMVpnEditorPlugin (to clarify that
it's unrelated to NMVpnPlugin), and add it to NetworkManager.h.
Rename NMVpnPluginUiWidgetInterface to NMVpnEditor, because it's not a
widget, and will soon be used for non-gui editing too. (Also, add a
placeholder for the method that non-gui editing will use.)
Fix the typedefs to not mix up the (dummy) NMVpnEditorPlugin and
NMVpnEditor types with the types of their interface structs. Update to
use G_DEFINE_INTERFACE.
Drop NMVpnPluginUiInterfaceProp; it doesn't matter what codes plugin
implementations use for the interface properties that they implement.
Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and
remove the two subclasses from the public API; while it's convenient
to still have both internally, they are now identical to the outside
world.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
The docs for NMIP4Config:addresses and NMIP4Config:routes claimed that
they were GPtrArrays of NMIP4Address/NMIP4Route, but get_property()
was actually trying to set them the D-Bus representation type, and it
was failing anyway because it used g_value_set_boxed() on a parameter
that was declared GParamSpecPointer. Fix it to use a GPtrArray-valued
property, and set it to the right thing.
NMIP6Config did the right thing with its :addresses and :routes
properties, but was using custom types (NM_TYPE_IP6_ADDRESS_OBJECT_ARRAY and
NM_TYPE_IP6_ROUTE_OBJECT_ARRAY). Make it use G_TYPE_PTR_ARRAY instead.
nm-types.c, nm-types.h, and nm-types-private.h are now empty, and so
can be dropped.
The fact that NMRemoteConnection has to be an NMConnection and
therefore can't be an NMObject means that it needs to reimplement bits
of NMObject functionality (and likewise NMObject needs some special
magic to deal with it). Likewise, we will need a daemon-side
equivalent of NMObject as part of the gdbus port, and we would want
NMSettingsConnection to be able to inherit from this as well.
Solve this problem by making NMConnection into an interface, and
having NMRemoteConnection and NMSettingsConnection implement it. (We
use some hacks to keep the GHashTable of NMSettings objects inside
nm-connection.c rather than having to be implemented by the
implementations.)
Since NMConnection is no longer an instantiable type, this adds
NMSimpleConnection to replace the various non-D-Bus-based uses of
NMConnection throughout the code. nm_connection_new() becomes
nm_simple_connection_new(), nm_connection_new_from_hash() becomes
nm_simple_connection_new_from_hash(), and nm_connection_duplicate()
becomes nm_simple_connection_new_clone().
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
Add NetworkManager.h, which includes all of the other NM header, and
require all external users of libnm to use that rather than the
individual headers.
(An exception is made for nm-dbus-interface.h,
nm-vpn-dbus-interface.h, and nm-version.h, which can be included
separately.)
