This speeds up the initial object tree load significantly. Also, it
reduces the object management complexity by shifting the duties to
GDBusObjectManager.
The lifetime of all NMObjects is now managed by the NMClient via the
object manager. The NMClient creates the NMObjects for GDBus objects,
triggers the initialization and serves as an object registry (replaces
the nm-cache).
The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
object creation, removal and property changes. It takes care of the
property changes so that we don't have to and lets us always see a
consistent object state. Thus at the time we learn of a new object we
already know its properties.
The NMObject unfortunately can't be made synchronously initializable as
the NMRemoteConnection's settings are not managed with standard
o.fd.DBus Properties and ObjectManager APIs and thus are not known to
the ObjectManager. Thus most of the asynchronous object property
changing code in nm-object.c is preserved. The objects notify the
properties that reference them of their initialization in from their
init_finish() methods, thus the asynchronously created objects are not
allowed to fail creation (or the dependees would wait forever). Not a
problem -- if a connection can't get its Settings, it's either invisible
or being removed (presumably we'd learn of the removal from the object
manager soon).
The NMObjects can't be created by the object manager itself, since we
can't determine the resulting object type in proxy_type() yet (we can't
tell from the name and can't access the interface list). Therefore the
GDBusObject is coupled with a NMObject later on.
Lastly, now that all the objects are managed by the object manager, the
NMRemoteSettings and NMManager go away when the daemon is stopped. The
complexity of dealing with calls to NMClient that would require any of
the resources that these objects manage (connection or device lists,
etc.) had to be moved to NMClient. The bright side is that his allows
for removal all of the daemon presence tracking from NMObject.
The assumption is not too useful to the library user anyway -- it could easily
be that there's some other link to the object in the object tree.
More importantly, when the objects are managed by the object manager,
we don't destroy the object until we see it actually removed on the
D-Bus. That makes more sense anyway.
Don't let a later property update finish than the sooner one.
This wouldn't happen most of time, apart from a special case when the
latter update of a object array property is to an empty list.
In that case the latter update would complete sooner and when the
earlier update finishes the list would contain objects which are
supposed to be gone already.
On D-Bus level, string (s) or object paths (o) cannot be NULL.
Thus, whenver server exposes such an object, it gets automatically
coerced to "" or "/", respectively.
On client side, libnm should coerce certain properties back, for which
"" is just not a sensible value.
For example, an empty NM_DEVICE_ETHERNET_HW_ADDRESS should be instead
exposed as NULL.
Technically, this is an API change. However, all users were well advised
to expect both NULL and "" as possible return values and handle them
accordingly.
No need to have two test-runners. Combine them, and call tests always
via "tools/run-nm-test.sh".
Yes, this brings an overhead, that we now always invoke the test with
a test wrapper script, also --without-vagrind. Previously, that was only
necessary for libnm tests that require their own D-Bus session.
Later we will do non-recursive Makefiles, thus all tests should have the
same LOG_COMPILER.
While technically it's already possible to implement a fail-over
mechanism using multiple connections (for example, defining a higher
priority DHCP connection with short DHCP timeout and a lower priority
one with static address), in practice this doesn't work well as we try
to autoactivate each connection 4 times before switching to the next
one.
Introduce a connection.autoconnect-retries property that can be used
to change the number of retries. The special value 0 means infinite
and can be used to try the connection forever. A -1 value means the
global configured default, which is equal to 4 unless overridden.
https://bugzilla.gnome.org/show_bug.cgi?id=763524
We connect signal handlers to devices when they appear, but don't
disconnect the handlers when the manager instance is destroyed. This
can cause crashes as device_ac_changed() is called on an invalid
manager instance.
Disconnect the handlers from dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383758
Backported symbols only make sense for libnm itself, not for
libnm-core which is statically linked with NetworkManager and
nm-ifcace-helper. Declaring the symbols in libnm-core, means
that NetworkManager binary also contains them, although there
are not used.
Move them to libnm.
Unnecessary APIs have been removed from nm-setting-proxy, client like
nm-connection-editor are expected to create a PAC script snippet the load
the location of file in NM.
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.
The team-config must be valid utf-8. First of all, JSON
is also defined for other unicode encodings, but libjansson
can only handle utf-8. So, just require that.
A file with a '\0' truncates part of the file and is thus
invalid.
Since we possibly already link against libjansson, we can also expose some
helper utils which allows nmcli to do basic validation of JSON without
requiring to duplicate the effort of using libjansson.
Also, tighten up the cecks to ensure that we have a JSON object at hand.
We are really interested in that and not of arrays or literals.
Every program run during the build which loads a NM library must
preload libasan.so if the address sanitizer is enabled.
Add a macro to set the needed environment variables and use it when
performing the shared object link tests.
Previously, when the load of an object failed and there were other
objects waiting for it, those objects would remain waiting
forever. Make them fail as well.
- don't include "nm-default.h" in header files. Every source file must
include as first header "nm-default.h", thus our headers get the
default include already implicitly.
- we don't support compiling NetworkManager itself with a C++ compiler. Remove
G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
users of libnm to use C++, thus they stay in public headers.
(cherry picked from commit f19aff8909)
Not default when linking with GOLD linker, but used for loading the VPN
plugins. We still get it when using NSS by dumb luck, but GnuTLS doesn't
drag it in.
https://bugzilla.gnome.org/show_bug.cgi?id=769328
Virtual devices don't have a valid permanent hw address: when activating
a connection against a specific interface, a check is performed on the
device MAC address too: if it is an empty string, give a try to the
currently assigned MAC address.
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
This new property be used as token to generate stable-ids instead
of the connection's UUID.
Later, this will be used by ipv6.addr-gen-mode=stable-privacy,
ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable
setting. Those generate stable addresses based on the connection's
UUID, but allow to use the stable-id instead.
This allows multiple connections to generate the same addresses
-- on the same machine, because in the above cases a machine
dependant key is also hashed.
The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.
Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via
$ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.
The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.
The NMVpnPluginInfo is essentially the .name file, that is, a
configuration file about the plugin itself. Via NMVpnPluginInfo
instance, the NMVpnEditorPlugin can be created.
Usually, one would create a NMVpnPluginInfo (that is, reading the
.name file) and then create a NMVpnEditorPlugin instance from there.
In this case, usually the editor-plugin is owned by the plugin-info
instance (although the API allows for creating the editor-plugin
independently).
Now, pass the NMVpnPluginInfo to the editor-plugin too.
This is useful, because then the editor-plugin can look at the .name
file.
The .name file is not user configuration. Instead it is configuration
about the plugin itself. Although the .name file is part of the plugin
build artefacts, it is useful to allow the plugin to access the .name
file. The reason is, that this can allow the user to easily change a
configuration knob of the plugin without requiring to patch or the
plugin.
Commit bdd0e7fec0 which added symbol
nm_setting_ip_config_get_dns_priority to libnm_1_4_0 was backported
to nm-1-2 in commit ad1cdcf657.
Add the backported symbol to master to allow seemless upgrading
from 1.2.4 to 1.4.0.
This adds two new options to the configure scripts to compile NM,
clients and libraries with the address and undefined-behavior
sanitizers available in recent GCC versions. Clang is not supported at
moment.
Add new Reload D-Bus command to reload NetworkManager configuration.
For now, this is like sending SIGHUP to the process. There are several
advantages here:
- it is guarded via PolicyKit authentication while signals
can only be sent by root.
- the user can wait for the reload to be complete instead of sending
an asynchronous signal. For now, we operation completes after
nm_config_reload() returns, but later we could delay the response
further until specific parts are fully reloaded.
- SIGHUP reloads everything including re-reading configuration from
disk while SIGUSR1 reloads just certain parts such as writing out DNS
configuration anew.
Now, the Reload command has a flags argument which is more granular
in selecting parts which are to be reloaded. For example, via
signals the user can:
1) send SIGUSR1: this writes out the DNS configuration to
resolv.conf and possibly reloads other parts without
re-reading configuration and without restarting the DNS plugin.
2) send SIGHUP: this reloads configuration from disk,
writes out resolv.conf and restarts the DNS plugin.
There is no way, to only restart the DNS plugin without also reloading
everything else.
Add a new "Config" property to the D-Bus interface for team devices
and show its value through "nmcli device show". The property contains
the full JSON configuration from teamd for the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
This is required to add objects in the "Types and Values" section and
in the API index. Later, we may want to add useful content in those
empty comments.
Otherwise NetworkManager can be too fast calling a method:
<error> [1461073999.2362] vpn-connection[0x7fe39ec491e0,be049803-a705-438f-b8f5-49db87640c93,"libreswan",0]:
plugin NeedSecrets request #1 failed: No such interface 'org.freedesktop.NetworkManager.VPN.Plugin'
on object at path /org/freedesktop/NetworkManager/VPN/Plugin
Contrary to nm_vpn_editor_plugin_load_from_file(), this allows
to specify a library name without path. In this case, g_module_open()
(dlopen()) will search for a library in various system directories.
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
The name_owner_chagned() unregisters the agent if NetworkManager goes away and
nmc_cleanup() also tries to unregister an agent, resulting in an assertion
failure:
# nmcli c up conn666
<daemon terminates>
Error: Connection activation failed: Message recipient disconnected from message bus without replying
(process:8746): libnm-CRITICAL **: nm_secret_agent_old_unregister: assertion 'priv->registered == TRUE' failed
_internal_unregister() already contains a priv->registered check and raising an
error on duplicate unregister attempt from a daemon after a restart is not a
problem either, since nmc_cleanup() doesn't care about the error returned
on teardown anyway.
Relax our error checking which will allow us to try harder to
make the best out of whatever NetworkManager sends us.
Also, drop the g_warning(). First, now we really don't expect this
function to fail. And even in that case, raising a g_warning() from
the library is not very friendly to the user of libnm.
When we receive a connection from NetworkManager it is not guaranteed
that the connection verifies. For example, if the current libnm version
is older then the NetworkManager version.
Be more accepting and don't do any verification of the connection.
For NMVpnPluginOld this change is uncritical, because there are probably
no users of this API anyway.
NMVpnServicePlugin is new API since nm-1-1. However, this API is already
strongly used by all the plugins we ported over. So this change is
affecting them.
This should only matter if libnm's and NetworkManager's version differ,
because NetworkManager just doesn't send out an invalid connection. It
actually only matters if NetworkManager is a newer version and sends an
invalid connection to the client. That is anyway badly tested and probably
this changes rather improves compatibility than breaking existing users.
When we receive a connection from NetworkManager it is not guaranteed
that the connection verifies. For example, if the current libnm version
is older then the NetworkManager version.
Be more accepting and don't do any verification of the connection.
This is a change in behavior in that we accept also invalid connections
and pass them down to the sub-classes.
Normalizing means that we fail on invalid connections.
Which can happen when the server is newer than the libnm
version. We just want to return whatever we can. The
caller should make sense of this.
This makes libnm more accepting and thus is not going to break
existing applications. Also, nm_device_get_applied_connection()
is new API since nm-1-1.
We're expecting four callbacks: a client::devices change,
client::active-connections change, client::activate callback,
and a device::active-connection change.
We only hook the second one in the callback to the first one, and
only if client::active-connections is not set already. If it is
(when running slowly in valgrind), we just decrement the counter.
However, as the counter is one less than it should be, it would
underflow and we wait forever* instead.
For the value of forever=20s, given that's the timeout of the
mockup service.
The new domain-suffix-match and phase2-domain-suffix-match properties
can be used to match against a given server domain suffix in the
dNSName elements or in the SubjectName CN of the server certificate.
Also, add a comment to the old subject-match properties documentation
to suggest that they are deprecated and should not be used anymore.
We don't want to update the properties until the objects referred are complete.
Otherwise the clients get confused. Very confused:
https://bugzilla.redhat.com/show_bug.cgi?id=1313866
We already delay the notification signals. Let's replace that with delaying the
actual ObjectCreatedData processing instead.
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>
If the plugin supports interactive mode, but the VPN binary (like vpnc
or openvpn) doesn't support it, then the plugin should return
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED from its connect_interactive()
hook. This lets NetworkManager know to fall back to plain Connect().
Since this notification is done through an error return, the VPN service
plugin code sees the failure and moves the plugin state back to
STOPPED. NetworkManager sees that state change, and terminates the
connection attempt while waiting for a reply to the Connect() method.
(VPN service plugins that don't support interactive mode at all don't
have this problem because that error is returned before the plugin's
state is moved to STARTING.)
To fix this, do two things:
1) if the connect_interactive() hook fails and returns the error
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED, postpone the STOPPED
state change for a few seconds to allow NM time to fall back to
plain Connect(). We still want to move the plugin state back to
STOPPED eventually, because otherwise it could stay in STARTING
forever.
2) change state to STARTING only if the connect/connect_interactive
plugin hooks were successful. Otherwise the plugin would still be
in STARTING state, and it's not valid to call Connect()/ConnectInteractive()
during the STARTING state.
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00091.htmlhttps://bugzilla.redhat.com/show_bug.cgi?id=1298732
- 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
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
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
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
"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.
The property is used to control duplicate address detection:
* -1 means default value
* 0 means no DAD is performed
* > 0 means timeout (in milliseconds) for arping responses
[bgalvani: moved setting from NMSettingIP4Config]
Add test showing how libnm/libnm-glib handles invalid connections,
i.e. connections that fail nm_connection_verify(). libnm implements
settings a static types (via different NMSetting types). This makes
it unavoidable that eventually a newer server version will
expose connections that fail verification in the client.
For example, master added a new base type NMSettingTun. This setting type
was not backported to legacy libnm-glib, thus such connection will not verify.
Also, we want that newer server versions are backward compatible with older
library versions. Thus also a pre-NMSettingTun libnm version has the same
problem.
The test shows that libnm is agnostic to whether the connection verifies.
That is consistent behavior, but possibly problematic because most
accessors to connections assert against a valid connection. Thus using
the common nm_connection*() functions on an invalid connection can lead
to problems.
Also, due to the static nature of our NMSetting types, some properties
can be silently dropped and thus mangling the connection without the
library user noticing.
libnm-glib prints a g_warning() whenever parsing an invalid connection.
When an invalid connection is added initially, it is exposed to the library
user. When a connection gets later invalidated due to an update, the
connection disappears and it stays missing even if a subsequent update
makes the connection valid again.
libnm-glib's behavior indicates that we might wanted to hide invalid
connections from the user. But it's very broken there.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
The unit tests for libnm and libnm-glib use a NetworkManager stub
service written in Python (test-networkmanager-service.py). As they
share the same server, it makes sense to also share the same utility
code to drive the stub.
Move the common code to include/.
Note that contrary to "nm-test-utils.h", "nm-test-libnm-utils.h" is not
a header-only file. Instead its implementation is in "nm-test-utils-impl.c".
The reason for that this split is, if we later have yet another non-header-only
test-utility, then all the implementations are in "nm-test-utils-impl.c", requiring
the tests to link only one object 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.
Add function nm_utils_enum_get_values() which returns a string array
containing the enum values. It can be used, for example, to build a
list of allowed values for user.
The property contains the fully qualified domain name to be sent to
DHCP server using the FQDN option. The property is mutually exclusive
with 'dhcp-hostname'.
for verifying the secrets, because it is not done in plain nm_setting_verify().
For simple verification of free-form string secrets,
_nm_setting_verify_secret_string() helper is used.
These properties limit whether the connection applies to a certain WWAN modem
based on the modem's device ID or SIM ID (as reported by the WWAN management
service), or through the MCC/MNC ID of the operator that issued the SIM card.
gi now emits a warning when not loading a specific library
version [1]:
./generate-setting-docs.py:21: PyGIWarning: NM was imported without specifying a version first. Use gi.require_version(NM, 1.0) before import to ensure that the right version gets loaded.
from gi.repository import NM, GObject
Seems require_version() is reasonably old to just always use it without
breaking on older versions [2].
[1] Related: https://bugzilla.gnome.org/show_bug.cgi?id=727379
[2] https://git.gnome.org/browse/pygobject/commit/?id=76758efb6579752237a0dc4d56cf9518de6c6e55
It is not used externally and its use might be confusing and undesired when we
add plugin aliases. The external users should only use the name when idenfiying
the plugin and nm_vpn_plugin_info_list_find_by_service() when matchin the plugin.
GLib introspection requires all types returned by public functions to
be GObjects, basic types or boxed types in order to correctly manage
resources. NMLldpNeighbor was a plain struct and GI complained with:
Warning: NM: nm_lldp_neighbor_new: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)
To fix this define NMLldpNeighbor as a boxed type.
Fixes: d3d2b49400
The plugins set state only on failures and often forget to do that. Do the
correct status transition to STOPPED in nm_vpn_service_plugin_failure() instead.
The get_state() is only used to find out whether to fail or orderly disconnect
depending on whether we're STARTING or already STARTED. Handle that in
nm_vpn_service_plugin_disconnect() in a generic manner instead.
Make it possible to construct the plugin instance in a way that disconnects the
connection if the DBus client that activated it drops off the bus. This makes the
plugins conveniently clean up when NetworkManager crashes.
We need this, as with multiple VPN support we can loose track of the client bus
names when the daemon crashes leaving to nice way to clean up on respawn.
However, this behavior is not desired for debugging or hypotetical VPN plugin
users other than NetworkManager (say; "gdbus call -m o.fd.NM.VPN.Plugin.Connect").
Let the plugin decide when to use it.
Document that the GPtrArray returned by
- nm_device_get_lldp_neighbors()
- nm_ip_config_get_addresses()
- nm_ip_config_get_routes()
is immutable and can be used by callers without the need of a copy.
Add the 'lldp' property to NMSettingConnection, which specifies
whether the reception and parsing of LLDP frames to discover neighbor
devices should be enabled.
This is intentionally IPv4 specific since this is used for a quick fallback to
method=link-local -- something that's not needed for IPv6 since the link local
address is always there.
https://bugzilla.redhat.com/show_bug.cgi?id=1262922
Otherwise the uninitializeded objects could be prematurely signalled if their
paths are seen twice in quick succession. This happens when you have ethernet
hardware and add an ethernet connection -- it's immediatelly added to
AvialableConnections and the property reload signals the object addition
before the NMRemoteSettings's GetSettings() finishes:
# nmcli c add type ethernet autoconnect no ifname '*'
(process:4610): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
#
https://bugzilla.gnome.org/show_bug.cgi?id=754794
We now (since 3272ff6 libnm/libnm-glib: don't quit in the middle of asking for
secrets) always hook on the quit timer when NM asks the plugin if it needs
secrets. The timer is 20 seconds, which seems too short.
Let's make it three minutes. Don't bother adding another timer or using a
distinct timeout: it does no harm for the plugin to remain unused for three
minutes on a bus.
Another option would be to completely unhook it; however the plugin wouldn't
learn if the user cancelled the NM's secrets request and would remain unused
on the bus forever.
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
connection_added() can be called before init_get_settings_cb(), and we can't
complete the connection until it is visible, else it would be uninitialized.
Test case:
* have 'em1' interface
$ nmcli con add type ethernet con-name myeth ifname em1 autoconnect no
(process:9039): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
$ nmcli con add type ethernet con-name myeth ifname em1X autoconnect no
Connection 'myeth' (71159504-c2af-4773-8ca9-a3626aa0da33) successfully added.
https://bugzilla.gnome.org/show_bug.cgi?id=754767https://bugzilla.gnome.org/show_bug.cgi?id=754794
[lkundrak@v3.sk: This is not quite the correct fix, we shouldn't emit
NMObject:connection-added for an unfinished object. Nevertheless, let's go with
it until we have a better one. Will revert this afterwards. See linked bugs.]
Otherwise the uninitializeded objects could be prematurely signalled if their
paths are seen twice in quick succession. This happens when you have ethernet
hardware and add an ethernet connection -- it's immediatelly added to
AvialableConnections and the property reload signals the object addition
before the NMRemoteSettings's GetSettings() finishes:
# nmcli c add type ethernet autoconnect no ifname '*'
(process:4610): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
#
https://bugzilla.gnome.org/show_bug.cgi?id=754794
Backport to 1.0.6 the following symbols:
- nm_setting_wired_get_wake_on_lan
- nm_setting_wired_get_wake_on_lan_password
- nm_setting_wired_wake_on_lan_get_type
added to 1.0.6 with commit d449d82304
API should be added with "Since:" of the next release on the same branch.
That means, new API on 1.1 branch (development), should be "Since: 1.2"
and new API on 1.0 branch (stable) will be "Since: 1.0.x". Similarly, new
API on master is NM_AVAILABLE_IN_1_2 and will be added with the linker
version libnl_1_2 -- never the versions of minor releases.
It is also strongly advised that for the 1.0 branch, we only add API
that was previously formerly added on master. IOW, that we only do true
backports of API that already exists on master.
API that gets backported, must also be added to master via NM_BACKPORT_SYMBOL().
That gives ABI compatibility and an application that was build against 1.0.x
will work with 1.y.z version (y > 0) without need for recompiling -- provided
that 1.y.z also contains that API.
There is one important caveat: if a major branch (e.g. current master) has a
linker section of backported APIs (e.g. libnm_1_0_6), we must do the minor release
(1.0.6) before the next major release (1.2). The reason is that after the major
release, the linker section (libnm_1_0_6) must not be extended and thus
the minor release (1.0.6) must be already released at that point.
In general, users should avoid using backported API because it limits
the ability to upgrade to arbitrary later versions. But together with the
previous point (that we only backport API to minor releases), a user that
uses backported API can be sure that a 1.y.z version is ABI compatible with
1.0.x, if the 1.y.z release date was after the release date of 1.0.x.
This reverts commit 02a136682c.
Backport to 1.0.6 the following symbols:
- nm_device_wifi_request_scan_options
- nm_device_wifi_request_scan_options_async
Backported by commit 91c0555afa
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
In hindsight, the NMVpnPluginOld should never have made public for
nm-1-0 as there are no users and we don't want to support this API.
For now, just deprecate it.
After copying "nm-vpn-plugin-old.*" to "nm-vpn-service-plugin.*",
rename the class and add it to the Makefile.
This will become the new VPN Service API for libnm 1.2. No changes
done yet except renaming of the classes and functions.
Rename the previous classes NMVpnPlugin(Old) to NMVpnServicePlugin
to have a distinct name from NMVpnEditorPlugin. Buth are plugins, but
with a different use.
https://bugzilla.gnome.org/show_bug.cgi?id=749951
Files are yet unchanged, only copy them to get a nicer history.
/bin/cp libnm/nm-vpn-plugin-old.c libnm/nm-vpn-service-plugin.c
/bin/cp libnm/nm-vpn-plugin-old.h libnm/nm-vpn-service-plugin.h
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.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Add a file containing the defines like DBUS_INTERFACE_DBUS from
dbus-shared.h, and use it from the gdbus-using files.
Also, convert a bunch of other places that were previously hardcoding
the string values to use the defines instead, and fix the ifcfg-rh
plugin to properly namespace its own D-Bus-related defines.
Add functions nm_utils_enum_to_str() and nm_utils_enum_from_str()
which can be used to perform conversions between enum values and
strings, passing the GType automatically generated for every enum by
glib-mkenums.
If the VPN plugin terminated and the user started it again, then the
quit timer will still be running and it sometimes happens that the
VPN plugin will quit while the UI is asking the user for secrets.
That's not very nice, so don't do that.
Reproducer: while connect to the VPN, suspend your laptop. Then
resume it, and immediately re-start the VPN connection. Watch the
secrets dialog disappear within a very short time.
https://bugzilla.gnome.org/show_bug.cgi?id=752237
This is done to silence coverity. In the dispatcher the existence of the
key is checked before and we're fine with leaving the value untouched
in the vpn-plugin-old.
The property is used for controlling whether slaves should be brought up with
a master connection. If 0, activating the master will not activate slaves.
But if set to 1, activating the master will bring up slaves as well.
The property can have the third state (-1), meaning that the value is default.
That is either a value set in the configuration file for the property, or 0.
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
Add a function to get a concise representation of the
device type.
libnm already has nm_device_get_type_description() for that
and it is shown by
nmcli -f GENERAL.TYPE device show
Reimplement that function for nm-core. Just take care that the
two implementations don't diverge.
The previous patch 9ffcecf86a was
completely wrong.
It tried to fix callers that provided a floating GVariant reference.
We require the caller to unref @secrets, so the correct fix it to
ensure that the reference is not floating.
Fixes: 9ffcecf86a
Fixes: 6793a32a8c
Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
(process:6888): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GDBusProxy'
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x0000003148e50c70 in g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
#1 0x0000003148e50eaf in g_log (log_domain=log_domain@entry=0x3149a3b224 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3149a42690 "invalid unclassed pointer in cast to '%s'") at gmessages.c:1079
#2 0x0000003149a34171 in g_type_check_instance_cast (type_instance=type_instance@entry=0x6fc530, iface_type=<optimized out>) at gtype.c:4030
#3 0x00007ffff7d6b016 in nmdbus_settings_connection_call_get_settings_finish (proxy=0x6fc530, out_settings=out_settings@entry=0x7fffffffdbb8, res=res@entry=0x6fe150, error=error@entry=0x0)
at nmdbus-settings-connection.c:1303
#4 0x00007ffff7ce8813 in updated_get_settings_cb (proxy=<optimized out>, result=0x6fe150, user_data=user_data@entry=0x6fc650) at nm-remote-connection.c:588
#5 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe150 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#6 0x000000314a2df47c in reply_cb (connection=<optimized out>, res=0x6fe0e0, user_data=user_data@entry=0x6fe150) at gdbusproxy.c:2623
#7 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe0e0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#8 0x000000314a2d48cc in g_dbus_connection_call_done (source=<optimized out>, result=<optimized out>, user_data=user_data@entry=0x7fffec01a320) at gdbusconnection.c:5502
#9 0x000000314a27640d in g_simple_async_result_complete (simple=0x6e5f40 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#10 0x000000314a27647c in complete_in_idle_cb (data=0x6e5f40) at gsimpleasyncresult.c:775
#11 0x0000003148e49b6b in g_main_context_dispatch (context=0x687970) at gmain.c:3064
#12 0x0000003148e49b6b in g_main_context_dispatch (context=context@entry=0x687970) at gmain.c:3663
#13 0x0000003148e49f08 in g_main_context_iterate (context=0x687970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3734
#14 0x0000003148e4a232 in g_main_loop_run (loop=0x687a80) at gmain.c:3928
#15 0x00000000004136a1 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:632
(gdb)
When a new connection is activated and presently active connection goes away,
the active-connection-removed signal is not emitted for the old connection.
This is what happens:
1.) Initially, nm-manager::active-connections = [ActiveConnection/old]
2.) First PropertyChange is signalled for the new connection addition:
nm-manager::active-connections = [ActiveConnection/old,ActiveConnection/new]
This triggers load of ActiveConnection/new object.
3.) Another PropertyChange is signalled for the old connection removal:
nm-manager::active-connections = [ActiveConnection/new]
This removes the ActiveConnection/old object from
nm-manager::active-connections and enqueues active-connection-removed
signal. The signal is not emmitted as there's a reload from 2.) in progress.
4.) ActiveConnection/new reload finished
object_property_complete() compares
[ActiveConnection/old,ActiveConnection/new] from its odata to current
nm-manager::active-connections and incorrectly concludes that
ActiveConnection/old was just added and removes the enqueued
active-connection-removed signal.
This patch fixes the issue by remembering the original
nm-manager::active-connections property value at 2.).
[thaller@redhat.com: fixed an integer overflow and odata->array unreffing]
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
When setting the certificate glib properties directly,
we raise a g_warning() when the binary data is invalid.
But since the caller has no access to the validation function,
he cannot easily check whether his action will result
in a warning. Add nm_setting_802_1x_check_cert_scheme() for
that.
nm_device_disambiguate_names() will disambiguate them by their
hardware address. This is not very helpful, so detect this case and
use the Bluetooth device name instead.
This function is used by System Settings when showing the list of
network devices.
https://bugzilla.gnome.org/show_bug.cgi?id=740553
(Port of a libnm-gtk patch written by Ryan Lortie.)
The newly added bond mode APIs in nm-utils will be new in 1.2, so mark
them as such in the headers and docs, move them to a new section in
libnm.ver.
Since we're adding the new section to libnm.ver, this also seems like
a good time to bump the soname.
Otherwise it does not register the "options" property and an assertion fails
when the user prints connection that has DHCPv6 options:
$ LIBNM_GLIB_DEBUG=properties-changed nmcli c show yolo
...
libnm-Message: Property 'options' unhandled.
...
(process:13522): libnm-CRITICAL **: nm_dhcp_config_get_options: assertion 'NM_IS_DHCP_CONFIG (config)' failed
I had argued for putting the local symbols in their own section, since
it doesn't make sense to have local symbols introduced in 1.2 in the
libnm_1_0_0 section... but apparently even if the section has no
exported symbols, rpm's find-provides still picks it up if it's there,
creating an ugly additional "provides" for libnm. So get rid of that.
Error: INFINITE_LOOP (CWE-835): [#def17]
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:93: loop_top: Top of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:94: loop_bottom: Bottom of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:93: loop_condition: If "notified" is initially true then it will remain true.
Error: INFINITE_LOOP (CWE-835): [#def18]
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_top: Top of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:192: loop_bottom: Bottom of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_condition: If "result & NOTIFY_MASK" is initially true then it will remain true.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_condition: If "result & SIGNAL_MASK" is initially true then it will remain true.
