| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
Make DHCPv6 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
|
| |
|
|
|
|
|
|
| |
Make DHCPv4 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Introduce the nm_device_ip_method_failed() function to check if the
failure of an IP method should cause the activation to fail, and use
it where appropriate.
http://bugzilla.gnome.org/show_bug.cgi?id=741347
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When performing NM package upgrade the new version of nmcli will be immediately
available while NM daemon will not, as it would not restart in order to avoid
to disrupt connectivity. This could create issues with tools leveraging
on nmcli output (till reboot). As apart from this case it is very unlikely
that a user can have this nmcli / NM daemon version mismatch situation,
the check could cause more harm than benefit in real user case
scenarios.
https://bugzilla.redhat.com/show_bug.cgi?id=1291785
|
| |
|
|
|
|
|
|
|
| |
The 'portname' sysfs attribute of s390 devices is deprecated since
kernel 4.4 and always set to 'no portname required'. But even on older
kernels such value must be interpreted as an unset portname and thus
ignored.
https://bugzilla.redhat.com/show_bug.cgi?id=1327204
|
| |
|
|
| |
They give each logging message a "manager: " prefix.
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1313091
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
Having a gateway defined when never-default=yes causes troubles in
connection matching and anyway makes no sense.
If the combination is found, remove the gateway during the
normalization phase.
https://bugzilla.redhat.com/show_bug.cgi?id=1313091
|
| |
|
|
|
|
| |
g_file_read_link() "reads" the symbolic link. If it's a relative path,
we get a relative path which is anchored on @file. We must resolve that
to be absolute.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The notification was missing from a long time. The issue has been exposed only
now due to the c57e5a6b66b8a29d4c16dacf9aafc7ee04a27243 fix which properly
implemented the "startup-complete" notification substituting out of place code
which masked the bug.
|
| |
|
|
|
|
|
| |
The top-level form was left on screen after exit (this is visible only
on some types of terminal as vt100), breaking automated tests.
Fixes: b2fb80928e27dc29240e604bab4f391302fc71f3
|
| |
|
|
|
|
|
|
| |
startup_complete
We connect to notify::startup-complete signal of each connection,
but after we signal startup-complete once, we don't need that
signal anymore. Disconnect.
|
| |\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=765387
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following settings are effectively identical:
dns=none,rc-manager=*any*
dns=none,rc-manager=unmanaged
dns=default,rc-manager=unmanaged
The new setting is only there for completeness and only
makes sense for a dns plugin.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Already previously, the mode and rc-manager were intertwined in a complicated
way:
- dns=none effectively disables rc-manager.
- if resolv.conf was immutable, it would disable the rc-manager
by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED".
- resolv_conf_mode was anyway a redundant piece of information to
rc_manager.
Now there are only two relevant settings: priv->plugin and
priv->rc_manager. And they can be set independently from each other.
Before that was not possible. For example, you could not set a
dns plugin with rc-manager=unmanaged (the only way to achive that
was via an immutable resolv.conf or by having rc-manager=symlink
and let resolv.conf link somewhere else.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The "dns" and "rc-manager" properties are strongly related. Initialize them
together in init_resolv_conf_mode().
One difference is, that we now set rc_manager before setting the mode.
But that shouldn't matter.
|
| | |
| |
| |
| |
| | |
Makes more sense in the next commit, when init_resolv_conf_manager()
gets merged with init_resolv_conf_mode(). Bear with me.
|
| |/
|
|
|
|
| |
We already have "rc-manager=file", rename "rc-manager=none" to "symlink"
because that better describes what it is actually doing. Of course, the
old name is still accepted.
|
| |\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=765464
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Generate a stable connection UUID for the default-wired-connection.
Otherwise, on every reboot, the UUID changes although the generated
connection is the same.
But also hash into the UUID the machine-id, the device name and the
hardware address. So, the UUID is only the same if the connection is
identical in every aspect.
Also, the UUID is used as Network_ID for the stable-privacy address
generation mode. It is bad to re-create different UUIDs on every boot
as it causes different addresses.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some device types, we use the DEVTYPE from sysfs to determine the
link type. However, the way we read from sysfs can race with device
renames and we could miss the chance to read DEVTYPE correctly.
This doesn't completely fix the sysfs race, but cures the boot-time race
with systemd renaming the device while we are initializing the link.
We ideally should use GUDev for all sysfs accesses, but that would need
some more work for this particular case as currently we need the link type
before we have an udev device instance.
https://bugzilla.gnome.org/show_bug.cgi?id=764803
Co-Authored-By: Beniamino Galvani <bgalvani@redhat.com>
|
| |
|
|
|
| |
Fixes: 89d1e466157839096b446068a780cb2563424a5a
Tested-by: Celti on IRC
|
| |
|
|
|
| |
The value cannot be unset. It must be set to one of the two currently
supported values.
|
| |
|
|
| |
(cherry picked from commit 3ad7be3e6a124fe9e279ec6d9de06c423ca50cc2)
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
| |
https://mail.gnome.org/archives/networkmanager-list/2016-April/msg00075.html
|
| |\
| |
| |
| | |
Some cleanup of "nm-sleep-monitor-systemd.c"
|
| | |
| |
| |
| |
| | |
The lifetime of the proxy is not necesarily the same as the lifetime
of the NMSleepMonitor instance. Disconnect the signals during dispose().
|
| | |
| |
| |
| |
| |
| | |
The daemon does not run with a particular locale of a user. Localizing
makes no sense (at least, we don't do it usually and it would make
logging localized).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As we don't take a reference on @self during the asynchronous
request, we must properly support cancelling in case of early
destruction.
I think, it's gdbus' responsibility not to leak any file descriptors
when cancelling a D-Bus request that returns file descriptors. Thus,
our usual pattern works here too.
|
| | |
| |
| |
| |
| | |
When destroing the sleep monitor before the D-Bus proxy is created,
we must cancel creation of the proxy.
|
| | | |
|
| | |
| |
| |
| |
| | |
To release resources, dispose() is preferred over finalize()
because it is called earlier.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
@error
Fixes: 07a9364d9c151bc3086a863759d31d0857ae011e
|
| |
|
|
| |
Fixes: 4271c9650c1cfcbd487cc471099b1c0c9bbfa290
|
| |
|
|
| |
Fixes: f15c412015647b378a187bdf98ccf8cd75eb0475
|
