If two users had the ability to control networking, and user1 started
a private connection which user2 cannot see, user2 could start their
own connection and disconnect user1's connection. This is not
consistent with device disconnection. A user who cannot see a
connection should not be able to start/stop it, even if they are
allowed to control networking in general.
This fixes a behaviour change made by 44ac1020da.
That commit make nm-online to wait for NM finishing startup instead of waiting
for a real connection. So for NetworkManager fully initialized, but
disconnected nm-online would return 0.
$ nmcli -f RUNNING,STATE,STARTUP,CONNECTIVITY gen status
RUNNING STATE STARTUP CONNECTIVITY
running disconnected started none
Revert back to the original behaviour of waiting for a connection. And
introduce a new option '--wait-for-startup' waiting for NetworkManager
finishing its startup, which is useful in some cases, like
NetworkManager-wait-online.service.
https://bugzilla.redhat.com/show_bug.cgi?id=1054364
NMClient's "devices" property was getting out of sync because the
daemon was emitting "notify" before actually changing the property
value. This resulted in problems with re-activating virtual devices
that had previously been deactivated in gnome-control-center and
anaconda. (And probably gnome-shell and nm-applet?)
$ /usr/sbin/fcoeadm -m fabric -c enp3s0f0
fcoeadm: Connection already created on interface enp3s0f0
Try 'fcoeadm --help' for more information.
$ echo $?
3
$
Also now log error output of failed commands instead of only when
debug logging is enabled.
First, lldpad doesn't support disabling priority groups (e:0)
without specifying a complete priority group config (which wouldn't
be used anyway, since you're turning it off!). While this bug is
being fixed upstream, we'll just ignore errors turning off
PG, since if you're using DCB on an interface, you probably want
to use it all the time.
Second, lldpad really wants all PG options on the same configuration
line, not split apart, because it validates the complete package
of options before applying them, regardless of whether or not they
are given in the same command. Since NM was just emitting all the
options in separate dcbtool invocations anyway, just combine them
all into a single invocation.
NmtNewtForm is an NmtNewtWidget, but previously it was only realizing
its child, not itself, which is technically wrong (though it had no
noticeable effect until get_realized() was added).
GLib registers number->string value transforms (meaning that
number-valued properties like NMSettingVlan:id or NMSettingWired:mtu
get loaded into their NmtNewtEntries correctly), but not the
corresponding string->number transforms (meaning changes made in the
entries don't get propagated back to the settings, and due to
http://bugzilla.gnome.org/show_bug.cgi?id=726574, there's no warning
about this). Fix this by registering our own transforms.
If you launched nmtui directly into the editor for a specific
connection, it would hang with a blank screen when you quit.
Fix this by changing the way startup works a bit, and have the created
toplevel NmtNewtForm get returned all the way to nmtui.c, which can
then connect to the "quit" signal on it and quit (rather than having
the different subprograms trying to guess whether they're supposed to
quit-on-exit or not).
nmt_newt_listbox_clear() did not reset active and active_key, which in
the case of NmtEditConnectionList meant that after the connection list
was rebuilt, the selection would appear to be in the same place, but
active_key would still point to the connection that used to be in that
row, rather than the one currently in that row, so if you immediately
hit Edit or Delete, you'd get unexpected results. (It also meant that
it was possible for the selection to land on a header row instead of a
connection row.)
This was particularly bad in the case of the Delete button, since
active_key would be left pointing to a freed NMConnection in that
case.
Fix NmtNewtListbox, and then add code to NmtEditConnectionList to
preserve the selection itself when rebuilding the list.
After applying a configuration with static IPv4 addresses, call
/sbin/arping to announce the new addresses to the host's neighbors.
(Basic idea copied from Fedora ifup-eth.)
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="23466771-f5fa-4ca9-856f-eaf4a8e20c3f"
BOOTPROTO=none
IPADDR="10.0.0.2"
PREFIX="24"
GATEWAY="10.0.0.1"
HWADDR="52:54:00:12:34:56"
TYPE=Ethernet
NAME="ens3"
This ifcfg file results in connection.interface-name=ens3.
However, device-generated connection didn't set interface-name property.
Fix that by setting interface-name property when generating a connection. Also
allow matching connections if interface-name is not set in a connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1077743
The AC doesn't get a D-Bus path until it's exported, but that happens after
it's handed to the Device it will be activated on. The Device emits a
PropertyChanged event when it's handed the AC, but it ignores ACs that
aren't exported yet. Thus when activating, the Device doesn't emit the
AC's path at all in the ActiveConnection property because it's NULL.
Fix that by exporting the AC immediately before starting activation
with it.
Second, move the notification of the Device.ActiveConnection property
to be emitted along with the state change to PREPARE instead of long
before it. While we don't guarantee signal ordering in general, this
seems like a more correct ordering.
https://bugzilla.gnome.org/show_bug.cgi?id=723783
If we find multiple plugins for the same type (eg, because the user
previously installed the "atm" and "bt" plugins, and didn't delete
them), log a warning.
The atm/adsl plugin really is a generic ATM plugin but (a) it needs a
bit of work to do IPoATM rather than just PPPoATM and PPPoEoATM, and
(b) most people currently using NM's ATM support are using DSL devices
not actual ATM cards anyway, and have no idea what "ATM" even means.
If we add the necessary IPoATM support later we can rename the plugin
back to -atm
nm_device_deactivate() is used when deactivating a device, but also
when initializing it when it is first managed. Rename it to
nm_device_cleanup(), and use a different log message ("preparing
device") in the NM_DEVICE_STATE_REASON_NOW_MANAGED case.
