This property is TRUE for devices that exist either as a kernel device
or are backed by some other resource (eg, ModemManager object, Bluez
device, etc). It will eventually be FALSE for software devices that
are not yet instantiated.
This enum was unused and meaningless because the platform signals
are emitted as a consequence of netlink messages. It is not clear
whether a netlink message was received due to an external event
or an internal action.
Can't just substitute sysconfdir into a header file -- it's meant to be
expanded in a Makefile. Otherwise, unexpanded ${prefix} will end up in a
header file.
We do that for NMCONFDIR already, let's use it here too.
Fixes: 2144457fab
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.
Old init-scripts that did not yet understand this key will have
mac-address-randomization explicitly disabled. This is to ensure
that old connections don't change behavior.
Thus, the writer must always write the value explicitly.
Downside is, if somebody creates a quick ifcfg-file, the feature
is disabled by default.
NMExportedObject now derives from GDBusObjectSkeleton, which is what
GDBusObjectManagerServer wants. The main GDBusConnection and each
private server connection now gets a new GDBusObjectManagerServer,
and exported objects are registered with that instead of individually
exporting each GDBusInterfaceSkeleton.
Previously exported objects were not referenced by the BusManager,
but instead removed from the exports hash via weak references. The
GDBusObjectManagerServer instead references exported objects, which
can make them live much longer than they did before.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Prevsiouly, the ifcfg-rh service and the regular NetworkManager
were both exported on the same D-Bus connection. That had the
effect, that on both services ("com.redhat.ifcfgrh1" and
"org.freedesktop.NetworkManager") all objects were visible.
This is also problematic later when we use GDBusObjectManager
for the org.freedesktop.NetworkManager service.
Export the ifcfg service on a separate bus connection.
One downside is, that we don't bother exporting the service
on the private socket and thus the service is not available
without D-Bus daemon.
Also, if the bus disconnects, we don't retry or recover. Instead
the D-Bus service is dead until restart.
Previously most objects were implicitly unexported when they were
destroyed, but since refcounts may make the object live longer than
intended, we should explicitly unexport them when they should no
longer be present on the bus.
This means we can assume that objects will always be un-exported
already when they are destroyed, *except* when quitting where most
objects will live until exit because NM leaves interfaces up and
running on quit.
If the current agent disappears and we already triggered the permission check
for it then the callback for that permission check will fire after we
progressed to the next agent:
# nmcli c --wait 0 up vpn
When another agent, such as GNOME Shell is registered, then get_done_cb() for
the nmcli will be called after we started the permission check for GNOME Shell,
resulting in an assertion fail:
get_done_cb: assertion 'call_id == parent->current_call_id' failed
Previsously, _LOGT() could be disabled at compile time. Thus it
was different then the other macros _LOGD(), _LOGI(), etc.
OTOH, _LOGt() was the macro that always was compiled in.
Swap the name of the macros. Now the upper-case macros are always
enabled, while the lower-case macro _LOGt() is enabled depending
on compile configuration.
Take a missing value in keyfile/ifcfg-rh as EUI-64 to keep the compatibility
with the old conneciton. Nevertheless, the new connections should default to
the RFC7217 addresses.
It might be that the user didn't supply the secrets in time and the dbus call
timed out. The agent should now hide the secrets dialog and we must let it know.
https://bugzilla.redhat.com/show_bug.cgi?id=1272023
Initscripts do:
oldifs=$IFS;
IFS=';';
[ -n "${ETHTOOL_DELAY}" ] && /bin/usleep ${ETHTOOL_DELAY}
for opts in $ETHTOOL_OPTS ; do
IFS=$oldifs;
if [[ "${opts}" =~ [[:space:]]*- ]]; then
/sbin/ethtool $opts
else
/sbin/ethtool -s ${REALDEVICE} $opts
fi
IFS=';';
done
IFS=$oldifs;
thus, we want to split on ';', otherwise we parse
"wol d;something else"
wrong.
Also, g_strsplit_set() returns multiple empty tokens. So
we must skip over empty tokens in case of "wol d".
The @use_password was wrong, because we would warn if sopass is specified
before wol:
"sopass AA:BB:CC:DD:EE:FF wol g"
More resilently handle wrong configurations:
"wol pu wol m" => gives m.
"wol pu wol" => should give NONE and warn (instead of "pu").
Also accept tab as separator.
Add a new 'ignore' option to NMSettingWired.wake-on-lan which disables
management of wake-on-lan by NetworkManager (i.e. the pre-existing
option will not be touched). Also, change the default behavior to be
'ignore' instead of 'disabled'.
https://bugzilla.gnome.org/show_bug.cgi?id=755182
Dracut when faced with an ipv6 only setup during kickstart will generate a ifcfg
file that sets the ipv4 address things to null but sets BOOTPROTO=static. This
makes network manager screw up because it expects an ipv4 address to be set.
Instead deal with this case by checking if we have any ipv4 addrs set, and if
not just disable ipv4. This fixes our inability to kickstart in our ipv6 only
clusters. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
https://mail.gnome.org/archives/networkmanager-list/2015-October/msg00015.html
Some initscripts variables can use "0" or "1" instead of more common
"yes", "no", for example REORDER_HDR.
And we also write REORDER_HDR=0|1 in writer.c, so we did not read REODER_HDR
correctly.
Fixes: ccea442504
The kernel defaults REORDER_HDR to 1 when creating a new VLAN, but
NetworkManager's VLAN flags property defaulted to 0. Thus REORDER_HDR was not
set for NM-created VLANs with default values.
We want to match the kernel default, so we change the default value for the
vlan.flags property. However, we do not want to change the flags for existing
connections if the property is missing in connection files. Thus we have to
update plugins for that. We also make sure that vlan.flags is always written
by 'keyfile' when the value is default. That way new connections have flags
property explicitly written and it will be loaded as expected.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
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
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
NMSecretAgent (and in turn NMAgentManager) used the @connection argument both
for the connection data, but also for the connection path. Detangle these, and
accept the path separate from the connection.
This makes NMSecretAgent and NMAgentManager truly operate on a plain
NMConnection, without the non-obvious requirement, that the path of the
connection must be set.
