| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and don't set ip6_state=IP_FAIL for ipv6.method=ignore.
The disabled state is like having an empty NMIP4Config object.
It should not result in %IP_FAIL state. Instead, we just want
to proceed and commit an empty NMIP4Config instance.
This was introduced by commit 0652d9c5961e4636eab87647af890aaf8c3e3269,
which I think was wrong.
Likewise, for ipv6.method=ignore we also don't want to mark the
IP state as failed. Instead, we want to proceed and set IP_DONE
right away -- without commiting anything, which is a difference
to the IPv4 case.
This is especially important, because an ip4_state/ip6_state of IP_FAIL
causes nm_device_can_assume_active_connection() to return FALSE, which
means we unmanage devices at shutdown. Ony might say that it doesn't
matter so much for a device without IP configuration, but imagine a
bond with VLANs on top that only has Layer 2 configuration. This will
bring down the entire stack.
With this change, devices with IP methods disabled/ignore stay up on
exit of NetworkManager (rh#1371126). Of course, that means on restart
software devices stay unamanged due to external-down (because since
commit e1edcda, devices without IP address are also external-down).
So, this really just fixes one scenario, breaking another one.
This should be fixed with bgo#746440 by not assuming connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1371126
|
|
|
|
|
| |
This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set
the IP state without commiting an NMIP[46]Config instance.
|
|
|
|
| |
and only if the activation stage is not about to fail hard.
|
|
|
|
|
| |
and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL.
They are only used during IP config stage. Give them a better name.
|
|
|
|
|
| |
We can express FINISH by returning SUCCESS and not set out_config in
act_stage3_ip4_config_start().
|
| |
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1372799
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For "cloned-mac-address", the empty string "" is an invalid
value that is rejected by verify().
Commit 8eed671 changed how the property is serialized to D-Bus.
Before, it was serialized using _nm_utils_hwaddr_to_dbus().
For invalid or empty addresses, this would not serialize the
value on D-Bus (or before commit 76aa6f8e0, it would create
a bogus value with no array elements).
With commit 8eed671, the cloned-mac-address gets also serialized
as "assigned-mac-address" via _nm_utils_hwaddr_cloned_data_synth(),
which would pass on invalid strings that the server would then reject.
That breaks for example nmtui. Try editing a connection with
"cloned-mac-address" set to NULL. Note, as long as you don't edit
the cloned MAC address in nmtui, you can save the modification.
Once you start modifying the entry, you can no longer set an empty
MAC address as the server now receives the invalid empty string.
Thus, the "OK" button fails with
Unable to save connection:
802-3-ethernet.cloned-mac-address:
is not a valid MAC address
It also means, nmtui cannot modify the "cloned-mac-address" field to
become empty.
Fix that problem at various places by coercing "" to NULL.
Fixes: 8eed67122c58540360b617eb42d5df8328e21b5d
https://bugzilla.redhat.com/show_bug.cgi?id=1372799
|
| | |
|
|/ |
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=887771
|
|
|
|
| |
Fixes: d568eb0e6c22f3828705530dd6d6cc34e79ae002
|
|\
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=770629
https://bugzilla.redhat.com/show_bug.cgi?id=1371920
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Nowadays, users should use the standard "PropertiesChanged" signal
on "org.freedesktop.DBus.Properties" interface.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before switching to gdbus (before 1.2.0), NetworkManager used dbus-glib.
Most objects in the D-Bus API with properties had a signal
NetworkManager-specific "PropertiesChanged" signal. Nowadays, this way of
handling of property changes is deprecated for the common "PropertiesChanged"
signal on the "org.freedesktop.DBus.Properties" interface.
There were a few pecularities in 1.0.0 and earlier:
(1) Due to the implementation with dbus-glib, a property-changed
signal was emitted on *all* interfaces. For example:
- a change on a NMDeviceVeth of "NMDeviceEthernet.HwAddress" would be
emitted both for the interfaces "fdo.NM.Device.Ethernet" and
"fdo.NM.Device.Veth". Note that NMDeviceVeth is derived from
NMDeviceEthernet and there is no "HwAddress" on veth device.
- a change of "NMVpnConnection.VpnState" was emitted on both
interfaces "fdo.NM.VPN.Connection" and "fdo.NM.Connecion.Active".
Note that NMActiveConnection is the parent type of NMVpnConnection and
only the latter has a property "VpnState".
(2) NMDevice's "fdo.NM.Device" interface doesn't have a "PropertiesChanged"
signal. From (1) follows that all property-changes for this type were instead
invoked with an interface like "fdo.NM.Device.Ethernet" (or multiple
interfaces in case of NMDeviceVeth).
1.2.0 introduced gdbus, which gives us the standard "fdo.DBus.Properties"
signal. However, it made the mistake of not realizing (1), thus instead
of emitting the signal once for each interface, it would pick the first
one in the inheritance tree.
With 1.4.0, a bug from merge commit 844345e caused signals for devices
to be only emitted for the interface "fdo.NM.Device.Statistics", instead
of "fdo.NM.Device.Ethernet" or "fdo.NM.Device.Veth" (or both).
The latter is what bgo#770629 is about and what commit 82e9439 tried to fix.
However, the fix was wrong because it tried to do the theoretically correct
thing of emitting the property-changed signal exactly once for the
interface that actually ontains the property. In addition, it missed that
NMDevice doesn't have a PropertiesChanged signal, which caused signals for
"fdo.NM.Device" to get lost *sigh*.
Now, restore the (broken) behavior of 1.0.0. These old-style property changed
signals are anyway considered deprecated and exist solely to satisfy old clients
and preserve the old API.
Fixes: 63fbfad3705db5901e6a2a6a2fc332da0f0ae4be
https://bugzilla.gnome.org/show_bug.cgi?id=770629
https://bugzilla.redhat.com/show_bug.cgi?id=1371920
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CAP_SYS_ADMIN
We don't want to enable this upstream, but make the requirement
more discoverable by documenting it and put a comment to
NetworkManager.service.
https://bugzilla.redhat.com/show_bug.cgi?id=1371201
|
| |
|
|
|
|
|
|
|
| |
L3-only devices don't have an ifindex during stage2, don't try to
start LLDP on them.
Fixes: 07a9364d9c151bc3086a863759d31d0857ae011e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After the fix in [1], if the connection is assumed we don't update its
firewall zone. The goal of that change was to prevent NM from
interfering with the configuration done externally on devices not
created by NM.
However if there is an assumed persistent connection active on the
device NM touches the configuration in other ways, for example it
configures DHCP and manages the default route. So it seems correct to
also update the firewall zone.
OTOH, if the connection is assumed-generated there is no persistent
connection specifying a firewall zone and updating it makes no sense.
Bug [1] was about not interfering with devices unknown to NM (for
which there is no persistent connection) and so this change should not
conflict with the previous fix.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1098281
https://bugzilla.redhat.com/show_bug.cgi?id=1366288
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=770629
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nm_exported_object_notify() hooks GObject's property-change signal
and searches for the D-Bus interface to which to send the
PropertiesChanged signal.
Then it would enqueue the value encoded as GVariant in pending_notifications.
However, thereby the association between the property that changed and the
interface was lost. So later in idle_emit_properties_changed() it would
just pick the first interface with a properties-changed-id.
That is wrong. pending_notifications must be associated with the D-Bus
interface that we are going to notify. That is, each InterfaceData must
have its own separate list.
This is broken since introducing NMExportedObject and moving to gdbus.
Only now it was discovered as NMDevice itself has two D-Bus interfaces:
"Device" and "Device.Statistics".
Note that the order of the PropertiesChanged in our D-Bus API is not defined
so that later signals can reach the receiver before earlier signals.
Also, multiple change signals for one property may be combined.
That is not changed by this patch and is not considered a bug, but something
that our D-Bus API wrt. PropertiesChanged does not guarantee.
https://bugzilla.gnome.org/show_bug.cgi?id=770629
|
|
|
|
|
|
|
|
|
| |
At this point we don't know if the slave has been using an assumed
connection that just vanished -- the best bet is to let the device be.
If it's meant to be unenslaved, it won't be due to an external event.
https://bugzilla.redhat.com/show_bug.cgi?id=1357738
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770515
|
|\
| |
| |
| | |
Restore the validation on team and team port configuration.
|
| |
| |
| |
| |
| | |
Restore the comments removed in commit
a524091966afb884cdb8db48067d5599a685a8eb.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Now that we validate the JSON syntax of a team/team-port
configuration, any existing connection with invalid JSON configuration
would fail to load and disappear upon upgrade. Instead, modify the
setting plugins to emit a warning but still load the connection with
empty configuration.
|
|/
|
|
|
|
|
| |
It's better to fail the validation of any invalid configuration
instead of silently ignoring it.
This reverts commit 476810c29016d569ac3885542a6c91e7af8a7f6d.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a software device unrealizes, we want to forget about the "user-explict"
unmanaged state. It means, that after a software device is deleted, the
"user-explict" managed flag will be cleared for that device.
It might be nice to preserve the managed-state after deletion of the device.
However, the unrealized-device only exists as long as we have a connection
for the device. That means, before this patch whether the unmanaged flag
was forgotten depends on whether the user had some connections that keep
the device alive as unrealized. That behavior was complicated, just don't
do that.
|
|
|
|
|
|
|
|
| |
There is a "goto retry" in do_change_link_request(), at that point,
seq_result has the value -EOPNOTSUPP, instead of
WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN.
Fixes: 02fb3eff481f79d3caa67fdde20b2ae7aa5e640b
|
|
|
|
| |
Fixes: 471521ca84187cd32afcd20aebe5a369fe7368dc
|
| |
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=770456
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems some drivers return success for nm_platform_link_set_address(),
but at that point the address did not yet actually change *sigh*.
It changes a bit later, possibly after setting the device up.
Add a workaround to retry reading the MAC address when platform indicates
success but the address still differs at first.
https://bugzilla.gnome.org/show_bug.cgi?id=770456
|
|/ |
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=770456
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=770456
|
|/ |
|
|
|
|
|
|
|
|
| |
Seems odd numbers may be coerced to the next-smaller even number.
Avoid that by using an even number for the test, as the number
has no particular meaning.
https://bugzilla.gnome.org/show_bug.cgi?id=765835
|
|
|
|
|
|
|
|
|
|
| |
This symbol is required to decide which version of certain IO functions
to use on various architectures. So we can't strip away the symbol from
the NetworkManager binary as this will lead to segfaults on those
architectures.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835550
https://bugzilla.gnome.org/show_bug.cgi?id=770515
|
|
|
|
|
| |
The code does the right thing as g_file_set_contents() will create
the temporary file using the label set by setfscreatecon().
|
|
|
|
| |
Fixes: c7cee12189d8fe64bc9037d5b9daaf1c887e0466
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770447
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770445
|
|
|
|
|
|
|
|
|
|
| |
Without this, it reads:
See the section called “Sections” for details.
but there are multiple sections called “Sections” and it should
explicitly refer to the one from the other top-level section.
With this change, it reads:
See “Sections” under the section called “CONNECTION SECTION” for details.
|