| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_handle_dbus_start()
../../src/nm-firewall-manager.c: In function ‘_handle_dbus_start’:
../../src/nm-firewall-manager.c:318:2: error: ‘dbus_method’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_dbus_proxy_call (priv->proxy,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dbus_method,
~~~~~~~~~~~~
arg,
~~~~
Fixes: d8bf05d3e695f043eeb0fac4646fc6babad1bee3
|
| |
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1449296
Fixes: 7307dea9c4da6cdc53e4c23c4ce07cf51bd0c4b7
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
no carrier
It's not the correct thing to do, but is the same behavior we've done
previously.
DAD is not even going to start until there's carrier and the client would
just wait indefinitely. Ideally, the client would choose not to waiat, but
it currently there's no way the client would discover what is going on.
https://bugzilla.redhat.com/show_bug.cgi?id=1446367
|
| |
|
|
|
|
|
|
| |
Since using libcurl for connectivity checks, we failed to build
with connectivity checking on travis. Fix that by installing the
required library (from trusty).
Fixes: 4e6967e33d912511f38b347c061cecb2ac4421fc
|
| |
|
|
|
|
| |
connectivity check functionality should be explicitly set as disabled if
not wanted: this prevents building NM without connectivity check support
without any evident warning on systems where libcurl is not installed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
devices
Commit #acf1067a allowed to assume connections on already managed
devices. Anyway, in complex scenario with layered connections, during
the startup of NetworkManager, this could interfere with the connection
assumption based on saved state.
So, avoid to re-assume connections on already managed devices during
startup.
Fixes: acf1067a455b02b60985e209df568d3fcc3fac9e
|
| |
|
|
|
|
|
|
|
|
| |
Set the @was_active flag for external activations with DHCP, so that
DHCP is retried multiple times in case of failure, as we do for
managed connections when the lease expires and for assumed
connections.
Fixes test: renewal_gw_after_dhcp_outage_for_assumed_var1
Fixes: e3113fdc4b01d79080911b7450fc032dc0a85108
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We check the return value of _get_stable_id(); when it is NULL
priv->ndisc would stay NULL too and we would crash when dereferencing
@error.
Actually, _get_stable_id() can never return NULL, so replace the check
with an assertion.
|
| |
|
|
|
|
|
|
|
|
| |
src/devices/nm-device-ip-tunnel.c:257:8: warning: Branch condition evaluates to a garbage value
if (local4)
^~~~~~
src/devices/nm-device-ip-tunnel.c:264:8: warning: Branch condition evaluates to a garbage value
if (remote4)
^~~~~~~
|
| |
|
|
|
|
|
|
|
|
| |
Now that routes can include optional attributes, print the expected
syntax in case of parsing failure.
$ nmcli connection modify dummy ipv4.routes a
Error: failed to modify ipv4.routes: invalid route: Invalid IPv4
address 'a'. The valid syntax is: 'ip[/prefix] [next-hop] [metric]
[attribute=val]... [,ip[/prefix] ...]'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the IPv6 methods require a non-tentative link local address
configured on the interface; we look at priv->ip6_config to determine
if such address exist. If the configuration is out-of-sync, we may
proceed with configuration when the link-local address does not exist
or is still tentative, especially because we toggle the "disable_ipv6"
sysctl parameter just before, which clears all IPv6 addresses on the
interface.
Ensure that priv->ext_ip6_config_captured is up-to-date before
continuing with the IPv6 configuration, and use it to determine
whether suitable addresses are present.
Fixes test: @ipv6_set_ra_announced_mtu
Fixes: 8f4caab60196132c2fd0eb4a444f93f78f130e8e
|
| |
|
|
|
|
|
|
| |
update_ip6_config() also removes addresses and routes no longer
present externally from the configuration, so it can't be called
before the changes are committed.
This reverts commit 8f4caab60196132c2fd0eb4a444f93f78f130e8e.
|
| |\
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=776276
https://bugzilla.redhat.com/show_bug.cgi?id=1421429
|
| | |
| |
| |
| |
| |
| | |
Add an example python script to show and set setting's
user-data. This is useful, as nmcli still doesn't support
user data.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The user data values are encoded in shell variables named
prefix "NM_USER_". The variable name is an encoded form of the
data key, consisting only of upper-case letters, digits, and underscore.
The alternative would be something like
NM_USER_1_KEY=my.keys.1
NM_USER_1_VAL='some value'
NM_USER_2_KEY=my.other.KEY.42
NM_USER_2_VAL='other value'
contary to
NM_USER_MY__KEYS__1='some value'
NM_USER_MY__OTHER___K_E_Y__42='other value'
The advantage of the former, numbered scheme is that it may be easier to
find the key of a user-data entry. With the current implementation, the
shell script would have to decode the key, like the ifcfg-rh plugin
does.
However, user data keys are opaque identifers for values. Usually, you
are not concerned with a certain name of the key, you already know it.
Hence, you don't need to write a shell script to decode the key name,
instead, you can use it directly:
if [ -z ${NM_USER_MY__OTHER___K_E_Y__42+x} ]; then
do_something_with_key "$NM_USER_MY__OTHER___K_E_Y__42"
fi
Otherwise, you'd first have to search write a shell script to search
for the interesting key -- in this example "$NM_USER_2_KEY", before being
able to access the value "$NM_USER_2_VAL".
|
| | |
| |
| |
| |
| | |
Hack keyfile reader support for NMSettingUser.
Writer support already works.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nm_setting_user_set_data() rejects invalid keys and values, and
can fail. This API is correct never to fail, like the get_data()
only returns valid user-data.
However, the g_object_set() API allows to set the hash directly but
it cannot report errors for invalid values. This API is used to
initialize the value from D-Bus or keyfile, hence it is wrong
to emit g_critial() assertions for untrusted data.
It would also be wrong to silently drop all invalid date, because
then the user cannot get an error message to understand what happend.
The correct but cumbersome solution is to remember the invalid values
separately, so that verify() can report the setting as invalid.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
vpn.data, bond.options, and user.data encode their values directly as
keys in keyfile. However, keys for GKeyFile may not contain characters
like '='.
We need to escape such special characters, otherwise an assertion
is hit on the server:
$ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value'
Another example of encountering the assertion is when setting user-data key
with an invalid character "my.this=key=is=causes=a=crash".
|
| | | |
|
| |/
|
|
| |
Fixes: 10661abe174862c71603cb385e20fee5a6671997
|
| | |
|
| |
|
|
| |
Fixes: 378cbca6f7cedec3ed8ac978feccec267f0f7069
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the IPv6 methods require a non-tentative link local address
configured on the interface; we look at priv->ip6_config to determine
if such address exist. If the configuration is out-of-sync, we may
proceed with configuration when the link-local address does not exist
or is still tentative, especially because we toggle the "disable_ipv6"
sysctl parameter just before, which clears all IPv6 addresses on the
interface.
Ensure that priv->ip6_config is up-to-date before continuing with the
IPv6 configuration.
Fixes test: @ipv6_set_ra_announced_mtu
|
| |
|
|
|
|
| |
Recently we removed libsoup dependency in favor of libcurl.
Connectivity checking functionality was enabled by defaut when libsoup
was detected: do the same now when detecting libcurl.
|
| | |
|
| | |
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1445242
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nm_device_update_firewall_zone() would only reconfigure the firewall
zone when the device is fully activated. That means, while the device
is activating, changing the firewall zone is not working. Activation
might take a long time with DHCP, or with master devices waiting
for their slaves.
For example:
nmcli connection add type team con-name t-team ifname i-team autoconnect no
nmcli connection up t-team
Note how t-team/i-team is waiting for a slave device. During stage3,
we already set firewall.zone to default.
nmcli connection modify t-team connection.zone external
Note how changing the firewall zone does not immidiately take
effect. Only later, during IP_CHECK state the firewall zone
is reset -- but only for devices with differing ip_ifindex.
https://bugzilla.redhat.com/show_bug.cgi?id=1445242
|
| |/
|
|
|
|
|
|
|
| |
For regular devices that don't have a separate ip_iface/ip_ifindex,
the ip_ifindex is left at zero. Hence, the condition is always
true and does not work as intended, resulting in setting the
firewall zone twice.
Fixes: 7cf5c326bc9a3e3166c682f3d70f65b895f2cd20
|
| |
|
|
|
|
|
|
|
|
| |
Commit 850c97795 ("device: track system interface state in NMDevice")
introduced interface states for devices and prevented checking if a
connection should be assumed on already managed devices.
This prevented to properly manage the event of an ip configuration added
externally to NM to a managed but not (yet) activated device.
Fixes: 850c977953e4de3c8bbee64a3d2e8726c971761c
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1443437
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If users wrote a FQDN in ipv4.dhcp-hostname presumably it's because
they really want to send the full value, not only the host part, so
let's send it as-is.
This obviously is a change in behavior, but only for users that have a
FQDN in ipv4.dhcp-hostname, where it's not clear if they really want the
domain to be stripped.
When the property is unset, we keep sending only the host part of the
system hostname to maintain backwards compatibility.
This commit aligns NM behavior to initscripts.
|
| |/
|
|
|
| |
Since they are mutually exclusive, pass a string and a boolean to
indicate whether we want to use the hostname or the FQDN option.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When a DHCP connection is active and the DHCP server is temporarily
unreachable, we restart DHCP for some times before failing the
connection. From the user point of view, restarting NM (and thus
assuming the existing connection) should not change this behavior.
However, if NM is restarted while the server is temporarily down, at
the moment we immediately fail because we consider the DHCP
transaction our first try. Fix this by restoring the multiple tries
when we detect that DHCP was active before because the connection is
assumed.
|
| |
|
|
|
| |
If we don't have connection checking functionality just avoid adding
a penalty to the defaut route of newly activated connections.
|
| |
|
|
|
|
|
|
|
|
| |
We call nm_device_activate_stage3_ipX_start() in various places,
e.g. after a carrier change or when a master enslaves a new device to
configure IP for the device. If the device is a slave in state
IP_CONFIG, this makes it transition to IP_CHECK, while it should stay
in IP_CONFIG until the master becomes ready. When the master is ready,
it will move slaves directly to SECONDARIES, skipping IP configuration
entirely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISC dhclient will always append the zero label to the fqdn.fqdn option.
The dhcp-options(5) suggest that it's perfectly fine to have an
unqualified name.
"... This can be a fully-qualified domain name, or a single label. ..."
The ISC dhcpd will ignore this trailing zero label and do DDNS
regardless.
https://bugzilla.gnome.org/show_bug.cgi?id=761467
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the operation is cancelled, we must not touch user_data. Note that
NM_POLICY_GET_PRIVATE() theoretically doesn't dereference the pointer
(does it?) but doing pointer arithmetic on a dangling pointer is a very
ugly thing to do.
And of course, the memleak.
Fixes: 5c716c8af8ddca1d3f7510494754d875b01a8889
Fixes: a2cdf632045d60b26f7aff470dedb56c1f9b938d
|
| |
|
|
|
|
|
|
|
|
| |
The default timeout in dhclient is 60 seconds; if a lease can't be
obtained during such interval, dhclient sends to NM a FAIL event and
then the IP method fails.
Thus, even if user specified a greater dhcp-timeout, NM terminated
DHCP after 60 seconds. Fix this by passing an explicit timeout to
dhclient.
|
| |
|
|
|
|
|
|
| |
Fixes compiler warning
comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare]
Fixes: 6ef59b5b776690097d28538db17e0ff8a3df84d5
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The PMF property is an GEnum, not GFlags. We only have the GObject
property NM_SETTING_WIRELESS_SECURITY_PMF as plain integer type
to allow for future extensions.
But commonly, enums are signed int, while flags are unsigned. Change
the property to be signed for consistency.
|
| | |
| |
| |
| |
| |
| | |
Drop some uses of "goto error". Instead, have the memory owned
by an auto variable and automatically release it via the cleanup
attribute.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
